General Business

🔍 Verification: Where applicable, confirm a technical/organisational mechanism exists to obtain verifiable consent from a parent before processing a child's personal data, with due diligence to confirm the parent is an identifiable adult (via reliable existing identity/age details, voluntarily provided details, or a virtual token via a Digital Locker service provider).

🔍 Verification: Confirm the organisation does not process children's personal data in a way likely to cause a detrimental effect on their well-being, and does not undertake behavioural tracking/monitoring or targeted advertising directed at children.

🔍 Verification: Determine whether any Data Principal is, or may be, under 18 years of age (a 'child' under Section 2(f)) - e.g., through employee dependents, customer demographics, or platform users. If not applicable, mark this section Not Applicable and document the basis for that conclusion.

🔍 Verification: Where applicable, confirm due diligence is performed to verify a lawful guardian of a person with disability is validly appointed (by a court, designated authority, or local level committee) before obtaining their consent for processing.

🔍 Verification: If the organisation is a clinical/mental-health establishment, healthcare professional, educational institution, or creche/childcare or associated transport provider, assess whether the conditional exemptions in the Fourth Schedule apply to specific processing (e.g., safety-related tracking). Not generally applicable to ordinary businesses.

🔍 Verification: Confirm consent capture is free, specific, informed, unconditional and unambiguous, involves a clear affirmative act (no pre-ticked boxes, no bundled/implied consent), and is limited to personal data necessary for the specified purpose.

🔍 Verification: Confirm the mechanism to withdraw consent is comparably easy to the mechanism used to give it; confirm that upon withdrawal, processing based on that consent ceases within a reasonable time (including by Data Processors), without affecting the legality of prior processing.

🔍 Verification: Review consent language and contracts for clauses that would be invalid to the extent they infringe the Act/Rules or other law - e.g., purported waivers of the right to complain to the Board.

🔍 Verification: Confirm every consent request is in clear and plain language, offers English/Eighth Schedule language options, and provides the business contact details of the DPO (if applicable) or the person authorised to respond to Data Principal communications.

🔍 Verification: Confirm the organisation can produce evidence, for any Data Principal, that a compliant notice was given and that consent was validly obtained, since the Data Fiduciary bears the burden of proof in any Board proceeding.

🔍 Verification: Where the organisation relies on a Section 7 legitimate use (e.g., 7(a) voluntarily provided data for a specified purpose, 7(i) employment-related processing) instead of consent, document the specific limb relied upon and why - do not blend legitimate-use processing into general consent language, and do not treat consent as the default basis for all processing.

🔍 Verification: If the organisation intends to route consent through a Consent Manager, confirm the Consent Manager is (or will be) registered with the Board once Rule 4 becomes active (13 Nov 2026), and that data-sharing arrangements with it are documented.

🔍 Verification: Identify every country/territory in which personal data is stored or processed, including cloud-hosting regions, and every foreign vendor/sub-processor involved.

🔍 Verification: Independently of the DPDP Act, check whether other Indian regulators (e.g., RBI for payment system data, sector regulators for specific data types) impose stricter data-localisation or cross-border transfer conditions that already apply to the organisation's data. These operate in addition to, not instead of, the DPDP Act.

🔍 Verification: The DPDP Act follows a 'restricted-country' (blacklist) approach, not a whitelist/adequacy approach - transfers are permitted by default except to countries or territories the Central Government specifically notifies as restricted. No such notification has been issued as of publication. Do not assume any particular country is either blocked or pre-approved; monitor for notifications.

🔍 Verification: Confirm contracts with foreign vendors/group entities receiving personal data address security safeguards, breach notification and data-return/deletion consistent with the organisation's own obligations under the Act.

🔍 Verification: Confirm a process exists to correct inaccurate/misleading data, complete incomplete data, update data, and erase data on request (unless retention is necessary for the specified purpose or legal compliance).

🔍 Verification: Confirm a process exists to give a Data Principal, on request, a summary of personal data processed and processing activities undertaken, plus the identities of other Data Fiduciaries/Data Processors with whom it has been shared (subject to the law-enforcement-sharing carve-out in Section 11(2)).

🔍 Verification: Confirm readily available means of grievance redressal exist, and that Data Principals are informed they must exhaust this internal route before approaching the Board.

🔍 Verification: Confirm the website/app prominently publishes the means to make a rights request and the identifying particulars (username, customer ID, email, mobile number, etc.) needed to verify the requester, and that requests are only actioned for Data Principals who previously gave consent to that Data Fiduciary.

🔍 Verification: Confirm a mechanism exists for a Data Principal to nominate another individual to exercise their rights in the event of death or incapacity.

🔍 Verification: Confirm requests are logged, tracked to resolution within a defined internal SLA, and that records are retained to demonstrate timely handling.

🔍 Verification: Confirm HR processing (payroll, performance, benefits, background checks, disciplinary records) relies on a documented basis - typically Section 7(i) (employment purposes / safeguarding the employer from loss or liability, e.g., trade secret protection) - rather than defaulting to employee 'consent', which is rarely freely given in an employment relationship.

🔍 Verification: Confirm the notice shown at account creation/purchase matches what the CRM system actually does with customer data (e.g., if data is used for cross-sell analytics beyond order fulfilment, that use must be disclosed and, where consent-based, separately consented to).

🔍 Verification: Confirm non-essential cookies/tracking technologies (analytics, advertising pixels) are deployed only after a compliant consent mechanism, distinct from essential/functional cookies.

🔍 Verification: Confirm candidates receive notice of what data is collected (CV, assessment results, references, background-check data) and for what purpose, and that unsuccessful-candidate data has a defined retention/deletion period.

🔍 Verification: Confirm marketing communications (email/SMS/WhatsApp/call) are sent on a valid consent basis with an easy opt-out that is honoured promptly and flows through to all channels/vendors used for that purpose.

🔍 Verification: Where CCTV footage or access-control logs are digitised/stored digitally and individuals are identifiable, confirm notice signage, defined retention period, restricted access, and a lawful basis (typically Section 7 legitimate use for safety/security) are in place.

🔍 Verification: Where email, internet-usage or device monitoring is conducted (e.g., for corporate-espionage prevention or confidentiality protection), confirm it is proportionate, documented, and disclosed to employees, consistent with the Section 7(i) purpose it relies on.

🔍 Verification: Confirm personal data shared with group/affiliate companies (e.g., shared services, global HR systems) is documented, has a lawful basis, and is disclosed in the ROPA/third-party register for Section 11 access-request purposes.

🔍 Verification: Confirm whether the organisation processes digital personal data of individuals within India, personal data collected in non-digital form and later digitised, or processes personal data of Data Principals in India from outside India in connection with offering goods or services to them. Confirm whether any processing falls under the personal/domestic-purpose exclusion or the publicly-available-data exclusion under Section 3(c).

🔍 Verification: For each processing activity, determine whether the organisation determines the purpose and means of processing (Data Fiduciary) or processes personal data on behalf of another entity (Data Processor) under a contract. An organisation can be both, for different activities.

🔍 Verification: Before assessing any other control, produce a first-pass map of what personal data is processed, for what purpose, and by which function - this map is the basis for the Data Inventory section below and for every subsequent control.

🔍 Verification: Nominate an accountable owner (formal Data Protection Officer if a Significant Data Fiduciary; otherwise a designated privacy/compliance owner) with authority to run this programme, coordinate with IT/HR/Legal/Vendor Management, and respond to Board or Data Principal communications.

🔍 Verification: Document an internal policy covering notice/consent standards, security safeguards, breach response, retention/erasure, Data Principal rights handling, and vendor management, consistent with this checklist.

🔍 Verification: Because the Act and Rules commence in phases (13 Nov 2025 / 13 Nov 2026 / 13 May 2027) and several matters are pending further Central Government notification (e.g., cross-border restricted-country list, Significant Data Fiduciary designation, data-localisation categories), assign someone to monitor the Official Gazette and MeitY announcements and update this checklist accordingly.

🔍 Verification: Confirm the business contact information of the DPO (if applicable) or another person able to answer Data Principal questions about processing is prominently published on the website/app, and included in every response to a rights-related communication.

🔍 Verification: Confirm an effective mechanism exists to redress Data Principal grievances relating to processing of their personal data or exercise of their rights.

🔍 Verification: Confirm the published grievance-response timeline does not exceed the period prescribed for the relevant class of Data Fiduciary, and that operational capacity exists to meet it.

🔍 Verification: Maintain a log of grievances received, actions taken, and time to resolution, including escalation where the internal route is exhausted and the Data Principal may approach the Board.

🔍 Verification: Verify every consent-seeking notice discloses, in clear and plain language: (a) an itemised description of the personal data being collected; (b) the specified purpose(s) and specific description of the goods/services or uses enabled; (c) how to exercise rights under Section 6(4) and Section 13; and (d) how to complain to the Board.

🔍 Verification: Confirm the notice can be understood on its own, without needing to cross-refer to other documents (e.g., a separate terms-of-service or unrelated policy) to make sense of what is being collected and why.

🔍 Verification: Confirm the workflow shows the notice to the Data Principal at or before the point consent is sought - not buried afterwards or only on request.

🔍 Verification: For Data Principals who gave consent before the relevant provisions commenced, plan to notify them, as soon as reasonably practicable after commencement, describing the personal data and purpose of processing, their rights, and how to complain to the Board. Consent given earlier remains valid until withdrawn.

🔍 Verification: Confirm the Data Principal has the option to access the notice in English or any language listed in the Eighth Schedule to the Constitution of India, at least on request.

🔍 Verification: Confirm an incident-response process exists to detect a personal data breach and escalate it internally without delay to the accountable privacy/security owner.

🔍 Verification: Confirm the breach-notification template covers: description of the breach (nature, extent, timing), consequences relevant to the Data Principal, mitigation measures taken/being taken, safety measures the Data Principal can take, and business contact details for queries - and that it can be delivered via the Data Principal's user account or registered communication channel without delay.

🔍 Verification: Confirm a process exists to intimate the Board without delay of the breach's nature, extent, timing, location of occurrence and likely impact upon becoming aware of it.

🔍 Verification: Confirm a process exists to provide the Board, within 72 hours of becoming aware of the breach (or such longer period as the Board allows on written request): updated/detailed description, facts/circumstances/reasons, mitigation measures, findings on the cause, remedial measures taken, and a report of the intimations given to affected Data Principals.

🔍 Verification: Confirm all actual and suspected breaches are logged in a central register with timeline, actions taken, and outcomes, and that relevant forensic evidence is preserved for investigation.

🔍 Verification: As best practice, conduct a post-incident review after any breach to identify root cause and track remediation to closure.

🔍 Verification: Document, per processing activity: categories of personal data processed, categories of Data Principals, purpose, and source of collection (direct from Data Principal, third party, public record, etc.).

🔍 Verification: For each processing activity in the ROPA, record whether the lawful basis is Data Principal consent (Section 6) or one of the 'certain legitimate uses' (Section 7, e.g., voluntarily provided data for a specified purpose, employment purposes, compliance with law, medical emergency). Do not default every activity to 'consent' - Section 7 uses have distinct conditions.

🔍 Verification: Identify which systems (HRMS, CRM, ERP, cloud storage, on-prem servers, email) store each category of personal data, and which internal roles/departments have access.

🔍 Verification: List every third party (Data Fiduciary or Data Processor) that receives personal data, including SaaS vendors, payroll providers, cloud hosts, auditors, and group companies, and note the country/jurisdiction in which each holds or processes the data.

🔍 Verification: For each data category, record the intended retention period, the event that triggers deletion (purpose fulfilled, consent withdrawn, statutory retention period under another law), and whether the organisation falls within any class specified in the Third Schedule to the Rules (see Retention section).

🔍 Verification: Confirm engagement of a Data Processor for any activity related to offering goods/services to Data Principals is under a valid written contract, since the Data Fiduciary remains responsible for compliance regardless of any contrary agreement (Section 8(1)).

🔍 Verification: Confirm DPAs require the processor to notify the Data Fiduciary promptly of any personal data breach, with enough detail to allow the Data Fiduciary to meet its own Board/Data Principal intimation timelines.

🔍 Verification: Cross-check the vendor list (payroll, HRMS, CRM, cloud hosting, email/marketing platforms, analytics, IT support, auditors, etc.) against the personal-data map to identify every processor handling personal data on the organisation's behalf.

🔍 Verification: Confirm DPAs contain appropriate provisions requiring the processor to take reasonable security safeguards and maintain confidentiality, and address sub-processor engagement and oversight.

🔍 Verification: Confirm DPAs require the processor to erase personal data made available to it when the Data Fiduciary is required to erase it (on consent withdrawal or purpose fulfilment), unless retention is required by law.

🔍 Verification: As good practice supporting the Section 8(5) security obligation, assess a vendor's security posture before onboarding and periodically thereafter (e.g., security questionnaires, certifications, audit rights).

🔍 Verification: Confirm personal data is erased once the Data Principal withdraws consent, or once it is reasonable to assume the specified purpose is no longer being served (i.e., the Data Principal has neither approached the organisation for that purpose nor exercised any rights, for the prescribed period), unless retention is necessary for compliance with law.

🔍 Verification: Confirm that when the organisation is required to erase personal data, it also causes each engaged Data Processor to erase the personal data made available to it for processing.

🔍 Verification: Confirm a retention schedule exists mapping each data category to a retention period justified by either ongoing purpose or a specific other-law requirement (e.g., tax, labour, corporate records law), and that deletion (including from backups, where feasible) is actually carried out on schedule.

🔍 Verification: Screen whether the organisation is a Data Fiduciary that is (a) an e-commerce entity with 2 crore+ registered users in India, (b) an online gaming intermediary with 50 lakh+ registered users in India, or (c) a social media intermediary with 2 crore+ registered users in India. If so, the specific 3-year erasure period (from last approach/rights exercise, or Rules commencement, whichever is later) and the 48-hour advance user notice under Rule 8(2) apply - these are covered in the relevant industry-specific checklist, not this general baseline. Most general businesses will mark this Not Applicable.

🔍 Verification: Rule 8(3) requires a Data Fiduciary to retain personal data, associated traffic data and other processing logs for a minimum of one year for the purposes specified in the Seventh Schedule (broadly, State/instrumentality functions and Significant-Data-Fiduciary assessment), after which they must be erased unless further retention is required by law. The precise scope of this obligation for ordinary private-sector processing is technical and should be confirmed with counsel rather than assumed.

🔍 Verification: Confirm appropriate data security measures are in place, such as encryption, obfuscation, masking, or use of virtual tokens mapped to personal data, at a minimum.

🔍 Verification: Confirm appropriate measures control access to the computer resources used to process personal data (role-based access, least privilege, authentication).

🔍 Verification: Confirm an overarching information-security programme documents the technical and organisational measures taken to ensure effective observance of the Act and Rules and prevent personal data breach.

🔍 Verification: Confirm appropriate logs, monitoring and review processes are in place to enable detection, investigation and remediation of unauthorised access.

🔍 Verification: Confirm reasonable measures (e.g., data backups) exist for continued processing in the event confidentiality, integrity or availability of personal data is compromised through destruction or loss of access.

🔍 Verification: Confirm logs and personal data relevant to detecting/investigating unauthorised access and supporting continued processing are retained for at least one year, unless another law requires otherwise.

🔍 Verification: As best practice supporting the general security obligation, run periodic vulnerability assessments/penetration testing and employee security-awareness training. These are not separately named as statutory requirements, but support the 'reasonable security safeguards' obligation.

🔍 Verification: If and when notified as an SDF, appoint a Data Protection Officer based in India, reporting to the Board of Directors or equivalent governing body, who acts as the point of contact for grievance redressal.

🔍 Verification: If and when notified as an SDF, appoint an independent data auditor to evaluate compliance with the Act.

🔍 Verification: If and when notified as an SDF, undertake a Data Protection Impact Assessment and audit at least once every 12 months, and furnish a report of significant observations to the Board.

🔍 Verification: No general list of Significant Data Fiduciaries has been notified as of the publication date of this checklist. Monitor Central Government notifications, which will designate specific Data Fiduciaries or classes based on volume/sensitivity of data processed, risk to Data Principal rights, potential impact on sovereignty/integrity, risk to electoral democracy, security of the State, and public order. Do NOT self-classify as an SDF without a notification or documented legal assessment.

🔍 Verification: If and when notified as an SDF, observe due diligence that algorithmic/technical measures used for processing do not pose a risk to Data Principal rights, and screen against any Central Government notification requiring specified categories of personal/traffic data not to be transferred outside India. No such category list has been notified as of publication.