DPDP Compliance Template Pack: 12 Ready-to-Use Documents

DPDP Compliance Template Pack: 12 Ready-to-Use Documents for Indian Businesses

April 2026 · ComplyDP Free Resource

Most companies know they need to comply with the DPDP Act. What stops them is not understanding the law - it is knowing what the actual documents should look like. What does a compliant privacy notice contain, word for word? What should a data principal rights request form include? What does a vendor data processing agreement look like under Indian law, not GDPR?

This template pack answers those questions with 12 ready-to-use documents, each mapped to the specific section of the DPDP Act and Rule it addresses. Every template has been reviewed against the Act's requirements by a practising Supreme Court Advocate and co-author of two practitioner books on the DPDP Act.

These are starting points, not legal advice. Customise them for your business, have your legal counsel review them, and treat them as the operational skeleton that your compliance infrastructure sits on.

How to Use This Pack

Each template below includes three things: the document itself in plain language, the DPDP Act section and Rule it maps to, and implementation notes explaining what to customise and what to leave as-is. Templates are organised by compliance workflow, not by section number, so you can work through them in order.

Template 1: Privacy Notice (Section 5, 6 + Rule 3)

This is the most important document in your compliance stack. Under Rule 3, the privacy notice must be a standalone document - not buried in your Terms of Service. It must be presented independently before or at the time of collecting personal data.

Required contents: - Itemised description of personal data being collected (not "we collect your information" - specify: name, email, phone number, device ID, location data, payment details, each listed separately) - Specific purpose for processing each data category (not "to improve our services" - specify: "to process your order," "to send transactional SMS," "to verify your identity for KYC") - Description of goods or services enabled by the processing - Contact details of the authorised person handling privacy queries (for SDFs, this must be the DPO) - Information about how to withdraw consent - Information about the right to file a complaint with the Data Protection Board of India - Language: must be available in English or any of the 22 languages in the Eighth Schedule to the Indian Constitution, based on user preference

What most companies get wrong: bundling the privacy notice with Terms of Service, using vague purpose descriptions, not offering language options, and not explaining withdrawal of consent clearly.

Template structure:

1. [Company Name] Privacy Notice
2. Effective Date: [Date]

What personal data we collect: [Table: Data category | Examples | Purpose | Legal basis]

How we use your data: [Purpose-specific descriptions, one per processing activity]

Who we share your data with: [Named categories of recipients with purpose for each]

How long we keep your data: [Retention periods by data category]

Your rights under the DPDP Act: - Right to access your personal data - Right to correction of inaccurate data - Right to erasure of personal data - Right to nominate another person to exercise your rights - Right to file a grievance with us - Right to file a complaint with the Data Protection Board of India

How to withdraw consent: [Step-by-step process - must be as easy as giving consent]

Contact us: [Name, email, phone of authorised person / DPO]

[Available in: English | Hindi | [other languages based on your user base]]

Implementation notes: Generate separate versions for each user-facing product or service. A single privacy notice for your entire company is non-compliant if different products collect different data for different purposes.

Template 2: Consent Collection Form (Section 6 + Rule 3)

Consent under DPDP must be free, specific, informed, unconditional, and unambiguous. This means: - No pre-ticked boxes - No bundled consent (you cannot condition core service access on consent to unrelated processing) - Each purpose must have a separate consent mechanism - Consent must be given through a clear affirmative action

Template structure:

[Company Name] - Consent for Processing Your Personal Data

We are requesting your consent to process the following personal data for the specific purposes listed below. You may accept or decline each purpose independently. Declining optional purposes will not affect your access to our core [product/service].

1. [Checkbox - unchecked by default] Purpose 1: [Specific description]
2. Data collected: [List]
3. Shared with: [Named recipients or "not shared"]

1. [Checkbox - unchecked by default] Purpose 2: [Specific description]
2. Data collected: [List]
3. Shared with: [Named recipients or "not shared"]

1. [Checkbox - unchecked by default] Purpose 3: [Specific description]
2. Data collected: [List]
3. Shared with: [Named recipients or "not shared"]

You can withdraw consent at any time by [specific method - must be as easy as giving consent].

By clicking "I Consent" below, you confirm that you have read our Privacy Notice and agree to the processing of your personal data for the purposes you have selected above.

[I Consent] [I Decline]

Implementation notes: Your consent UI must record: timestamp of consent, specific purposes consented to, version of the consent form shown, language of the form, and method of consent (click, tap, signature). These records must be maintained as audit-ready consent artefacts.

Template 3: Data Principal Rights Request Form (Section 11–14)

Under the DPDP Act, individuals have the right to access, correct, erase, and nominate. You need a standardised intake form and a backend workflow that can process requests within the prescribed timelines.

Template structure:

Data Principal Rights Request

Your details: Full name: ___ Email associated with your account: ___ Phone number (optional): ___ Any other identifier we can use to locate your data: ___

What would you like to do? (Select one)

[ ] Access - I want to know what personal data you hold about me, the purposes it is used for, and who it has been shared with.

[ ] Correction - I want to correct inaccurate or incomplete personal data you hold about me. Details of correction needed: ___

[ ] Erasure - I want you to delete my personal data. I understand that erasure may affect my ability to use [product/service] if the data is necessary for its functioning.

[ ] Nomination - I want to nominate someone to exercise my data rights on my behalf. Nominee name: ___ Nominee contact: ___ Relationship: ___

Verification: To protect your data, we will verify your identity before processing this request. We may contact you at the email or phone number above to confirm.

Expected timeline: We will acknowledge your request within [X] business days and complete processing within [X] days, as required under the DPDP Act.

Implementation notes: Build an internal SLA tracker. Erasure requests where processing has no ongoing lawful basis must be completed within 7 days. Log every request, every action taken, and every communication - this is your audit trail if the DPBI investigates.

Template 4: Data Breach Notification to the DPBI (Section 8(6) + Rule 8)

You have 72 hours from detection to notify the Data Protection Board of India. This template should be pre-filled with your company details and stored in your incident response runbook so that under pressure, your team fills in the breach-specific details rather than drafting from scratch.

Template structure:

1. Personal Data Breach Notification
2. To: Data Protection Board of India
3. From: [Company Name], [Registration/CIN number]
4. Date of notification: [Date]
5. Date and time of breach detection: [Date, Time]

1. Nature of the breach: [Unauthorised access / Unauthorised disclosure / Data loss / Ransomware / Other]

2. Description of the incident: [What happened, how it was detected, initial assessment of cause]

3. Categories of personal data affected: [e.g., names, email addresses, phone numbers, financial data, health data, biometric data]

4. Approximate number of Data Principals affected: [Number or best estimate]

5. Likely consequences of the breach: [Risk assessment: identity theft, financial loss, reputational harm, discrimination, etc.]

6. Measures taken to contain the breach: [Steps already taken: systems isolated, passwords reset, access revoked, etc.]

7. Measures taken to mitigate impact on Data Principals: [Notifications sent, credit monitoring offered, etc.]

8. Contact person for this notification: Name: ___ Designation: ___ [DPO if SDF] Email: ___ Phone: ___

9. Additional information: [Any other relevant details, including whether law enforcement has been informed]

Signed: [Authorised signatory]

Implementation notes: Run a tabletop exercise with this template before you need it. Time your team: can they fill it out accurately within 72 hours of a simulated breach? If not, identify the bottleneck (usually it is "approximate number of Data Principals affected" because nobody has a data inventory that can answer that quickly).

Template 5: Data Breach Notification to Affected Data Principals (Section 8(6) + Rule 8)

Separate from the DPBI notification. This goes to the individuals whose data was compromised.

Template structure:

Important Notice: Your Personal Data May Have Been Affected

Dear [Name / "Valued Customer"],

We are writing to inform you of a personal data security incident that may have affected your information.

What happened: [Plain-language description - no jargon, no minimisation]

When it happened: [Date of breach / date of detection]

What data was involved: [Specific categories - not "some of your information"]

What we are doing: [Concrete steps taken - not "we take your privacy seriously"]

What you can do: [Specific protective actions the individual can take]

How to contact us: [Name, email, phone of the person handling queries about this breach]

Your rights: You have the right to file a complaint with the Data Protection Board of India at [contact details / website].

We sincerely regret this incident and are committed to preventing it from happening again.

[Signed by a named senior executive, not "The [Company] Team"]

Implementation notes: Do not use PR language. Do not say "we take your privacy seriously" - it is meaningless and erodes trust. Be specific about what happened, what data was exposed, and what you are doing. Specificity is what separates a company that handles a breach well from one that becomes a case study in what not to do.

Template 6: Consent Withdrawal Mechanism (Section 6(4))

Withdrawal must be as easy as giving consent. If consent was given via one click, withdrawal must also be one click. This template covers both the UI flow and the backend process.

Template structure:

Manage Your Consent Preferences

You previously consented to the following data processing activities. You can withdraw consent for any or all of them below. Withdrawing consent will not affect the lawfulness of processing done before withdrawal.

1. [Toggle - currently ON] Purpose 1: [Description]
2. Last consented: [Date]

1. [Toggle - currently ON] Purpose 2: [Description]
2. Last consented: [Date]

1. [Toggle - currently ON] Purpose 3: [Description]
2. Last consented: [Date]

[Save Changes]

When you withdraw consent: - We will stop processing your data for that purpose within [X] hours - We will delete data collected for that purpose within [X] days, unless retention is required by law - Your access to [core service] will not be affected [if true - if consent withdrawal affects service access, state this clearly]

Implementation notes: The "as easy as giving consent" requirement is the one most companies fail. If giving consent requires one tap in your app, withdrawal must also require one tap - not an email to support@company.com, not a 5-step settings flow, not a phone call. Build the withdrawal UI at the same time as the consent UI, not as an afterthought.

Template 7: Vendor/Processor Data Processing Agreement - DPDP Clauses (Section 8(2))

Every contract with a data processor must include specific DPDP-aligned provisions. This template provides the clauses to insert into your existing vendor agreements.

Template structure:

Data Processing Addendum - DPDP Act Compliance

This addendum is entered into between [Data Fiduciary] ("Company") and [Data Processor] ("Processor") and forms part of [Master Agreement dated ___].

1. Definitions: [Align with DPDP Act definitions - Data Fiduciary, Data Processor, Data Principal, Personal Data, Processing]

2. Scope of processing: Processor shall process personal data only for the purposes specified in Schedule A, and only on documented instructions from the Company.

3. Security safeguards: Processor shall implement reasonable security safeguards as required under Section 8(4) of the DPDP Act, including but not limited to: - Encryption of personal data at rest and in transit - Access controls limiting data access to authorised personnel - Logging and monitoring of data access - Regular security assessments

4. Sub-processing: Processor shall not engage a sub-processor without prior written consent of the Company. Any sub-processor must be bound by obligations no less protective than those in this addendum.

5. Data Principal rights: Processor shall assist the Company in fulfilling Data Principal rights requests (access, correction, erasure, nomination) within the timelines prescribed by the Act.

6. Breach notification: Processor shall notify the Company of any personal data breach without undue delay, and in any event within [24/48] hours of becoming aware of the breach, providing sufficient information for the Company to meet its 72-hour notification obligation to the DPBI.

7. Data deletion: Upon termination of this agreement or upon request by the Company, Processor shall delete all personal data processed on behalf of the Company within [30] days and provide written certification of deletion.

8. Audit rights: Company shall have the right to audit Processor's compliance with this addendum, either directly or through an independent auditor, upon [30] days' written notice.

9. Cross-border transfers: [If applicable] Processor shall not transfer personal data outside India except to countries or territories permitted under Section 16 and Rule 15 of the DPDP Act.

10. Indemnification: Processor shall indemnify the Company for any penalties, losses, or damages arising from Processor's breach of this addendum or failure to comply with the DPDP Act.

1. Schedule A: Processing Details
2. - Categories of Data Principals: [e.g., customers, employees, vendors]
3. - Categories of personal data: [e.g., names, contact details, transaction records]
4. - Purposes of processing: [Specific purposes]
5. - Duration: [Duration of processing]
6. - Retention period: [How long Processor may retain data after processing is complete]

Implementation notes: Insert this as an addendum to every existing vendor agreement where the vendor processes personal data on your behalf. Prioritise: cloud hosting providers, payment processors, analytics vendors, marketing automation tools, HR/payroll systems, and customer support platforms.

Template 8: Data Retention and Erasure Policy (Section 8(7))

Personal data must be erased once the purpose of collection is complete and consent has lapsed, unless a legal retention obligation applies.

Template structure:

1. [Company Name] Data Retention and Erasure Policy
2. Version: [X.X]
3. Effective date: [Date]
4. Next review date: [Date + 12 months]

Purpose: This policy defines how long [Company Name] retains categories of personal data and the processes for erasure when retention is no longer lawful.

Retention schedule:

1. [Table format]
2. Data category | Purpose | Retention period | Legal basis for retention | Erasure method
3. Customer account data | Service delivery | Duration of account + [X] months | Consent / Contract | Automated deletion from all systems including backups
4. Transaction records | Financial compliance | [X] years | Legal obligation (Companies Act, GST) | Secure deletion after statutory period
5. Marketing consent records | Audit trail | [X] years after consent withdrawal | Legitimate record-keeping | Archived, then deleted
6. Employee data | HR and payroll | Duration of employment + [X] years | Legal obligation (labour laws, PF, tax) | Secure deletion after statutory period
7. Support ticket data | Customer service | [X] months after resolution | Consent | Automated deletion

Erasure process: 1. Automated triggers: System flags data for review when retention period expires 2. Manual review: Privacy team confirms no ongoing legal obligation to retain 3. Deletion execution: Data deleted from primary systems, backups, caches, and third-party processors 4. Deletion verification: Automated confirmation that data no longer exists in any system 5. Deletion log: Record of what was deleted, when, by whom, and from which systems - retained for audit purposes

Special cases: - Data subject to litigation hold: retained until hold is lifted, regardless of retention period - Data subject to regulatory investigation: retained until investigation is concluded - Backup deletion: backups containing expired data must be purged within [X] days of next scheduled backup rotation

Implementation notes: The biggest gap in most companies is backup deletion. Your primary database may delete a user's data within 7 days, but if your backup system retains it for 90 days, you are non-compliant for 83 of those days. Map your backup architecture before setting retention periods.

Template 9: Children's Data Processing Consent (Section 9)

Processing personal data of children (under 18) requires verifiable parental consent. Behavioural tracking and targeted advertising directed at children is prohibited.

Template structure:

Parental Consent for Processing Your Child's Personal Data

[Company Name] takes the protection of children's personal data seriously. Under the Digital Personal Data Protection Act, 2023, we require verifiable consent from a parent or legal guardian before processing any personal data of a person under 18 years of age.

Your child's details: Name: ___ Date of birth: ___

Your details (parent/legal guardian): Name: ___ Relationship to child: ___ Contact email: ___ Contact phone: ___

We are requesting your consent to process your child's personal data for the following purposes:

1. [Checkbox] Purpose 1: [Specific description - e.g., "to create a student account on our learning platform"]
2. Data collected: [List]

1. [Checkbox] Purpose 2: [Specific description]
2. Data collected: [List]

Important: We do not engage in behavioural monitoring or targeted advertising directed at children. This is prohibited under the DPDP Act.

Verification: We will verify your identity as the parent/legal guardian through [method - e.g., OTP to registered phone, government ID verification, video call].

You can withdraw this consent at any time by [method]. Upon withdrawal, we will delete your child's data within [X] days.

[I Consent as Parent/Legal Guardian] [I Decline]

Implementation notes: "Verifiable" parental consent is the key word. A simple checkbox claiming "I am over 18" does not meet the standard. Implement age-gating with verification - OTP to a parent's phone number, government ID check, or other method appropriate to your risk level. EdTech companies take note: this is not optional for you.

Template 10: DPIA Template for SDFs (Rule 7)

Significant Data Fiduciaries must conduct Data Protection Impact Assessments for high-risk processing activities.

Template structure:

1. Data Protection Impact Assessment (DPIA)
2. [Company Name]
3. Assessment date: [Date]
4. Assessor: [Name, designation]
5. Processing activity: [Name/description]
6. Business owner: [Name, designation]

1. Description of processing: - What personal data is processed? [Categories and volumes] - Why is it processed? [Specific purposes] - How is it processed? [Technical description - collection method, storage, sharing, automated decision-making] - Who has access? [Roles and departments] - How long is it retained? [Retention period] - Is it transferred outside India? [If yes, to which countries/territories]

2. Necessity and proportionality: - Is the processing necessary for the stated purpose? [Assessment] - Could the purpose be achieved with less data or less intrusive processing? [Assessment] - Is the data collected proportionate to the purpose? [Assessment]

3. Risks to Data Principals: [Table: Risk | Likelihood (Low/Medium/High) | Severity (Low/Medium/High) | Overall risk rating] - Unauthorised access or disclosure - Inaccurate data leading to wrong decisions - Excessive data collection - Lack of transparency - Inability to exercise rights - Discriminatory outcomes from automated processing - Re-identification risk from anonymised data

4. Mitigation measures: [Table: Risk | Mitigation measure | Implementation status | Responsible person | Target date]

5. Consultation: - Has the DPO been consulted? [Yes/No - date and outcome] - Have affected Data Principals or their representatives been consulted? [If applicable] - Have technical security experts been consulted? [Yes/No - date and outcome]

6. Decision: - Proceed with processing as described [ ] - Proceed with additional safeguards (described above) [ ] - Do not proceed - risks outweigh benefits [ ]

1. Approved by: [DPO / Senior management]
2. Review date: [Date + 12 months or upon material change to processing]

Implementation notes: Run a DPIA before launching any new product feature that processes personal data at scale, uses automated decision-making or profiling, processes children's data, or involves systematic monitoring. Do not treat DPIAs as a post-launch compliance exercise - they are meant to be conducted before the processing begins.

Template 11: Employee Privacy Notice (Section 5, 6 - internal)

Your employees are Data Principals too. Most companies forget this. HR data - payroll, performance reviews, health records, biometrics for attendance - all falls under DPDP.

Template structure:

[Company Name] Employee Privacy Notice

This notice explains how [Company Name] collects, uses, and protects your personal data as an employee. This notice is separate from your employment contract and applies to all employees, contractors, and interns.

What personal data we collect about you:

1. [Table: Data category | Examples | Purpose]
2. - Identity data: name, date of birth, photograph, government IDs (Aadhaar, PAN) | Employment records, KYC, statutory compliance
3. - Contact data: address, personal email, phone number | Communication, emergency contact
4. - Financial data: bank account details, PAN, salary details | Payroll processing, tax deductions
5. - Attendance data: biometric data (if applicable), login times, leave records | Attendance tracking, payroll calculation
6. - Performance data: appraisals, feedback, training records | Performance management, career development
7. - Health data: medical certificates, insurance claims, disability information | Insurance administration, leave management
8. - Device data: company device logs, email metadata (if monitored) | IT security, acceptable use policy enforcement

Legal basis: Most employee data processing falls under the "legitimate use" exception for employment purposes (Section 7(a)). This means we generally do not need separate consent for standard HR activities like payroll, benefits, and statutory compliance. However, consent is required for processing that goes beyond what is necessary for employment - for example, using employee photos in marketing materials.

Your rights as a Data Principal: [Same rights as customer-facing notice - access, correction, erasure, nomination, grievance]

How to exercise your rights: [Contact details - typically HR or DPO]

Retention: Your data is retained for the duration of your employment plus [X] years as required by applicable labour laws, Companies Act, PF Act, and tax regulations.

Implementation notes: Issue this notice to every employee and collect acknowledgment. Store acknowledgments as audit evidence. If you use biometric attendance systems, get explicit consent - biometric data processing is not covered by the employment legitimate use exception.

Template 12: Annual Compliance Review Checklist (Rule 7, Rule 8)

Use this quarterly/annually to verify your compliance posture remains current.

1. [Table format]
2. Control area | Requirement | Status (Compliant/Partial/Non-compliant) | Evidence | Owner | Next action | Due date

1. Privacy notices | Standalone, purpose-specific, multilingual | ___ | [Link to current notice] | Legal | ___ | ___
2. Consent mechanisms | Granular, purpose-specific, easy withdrawal | ___ | [Link to consent UI] | Product | ___ | ___
3. Data inventory | Complete, current, covers all systems | ___ | [Link to inventory] | IT/Privacy | ___ | ___
4. DSR workflow | Operational, tested, within SLA | ___ | [Test results] | Privacy/Eng | ___ | ___
5. Breach response | Tested within last 12 months, 72-hour capable | ___ | [Tabletop exercise report] | CISO/Privacy | ___ | ___
6. Vendor agreements | DPA clauses in all processor contracts | ___ | [Contract tracker] | Legal/Procurement | ___ | ___
7. Employee training | Conducted within last 12 months | ___ | [Training records] | HR/Privacy | ___ | ___
8. Retention policy | Current, implemented in systems | ___ | [Retention schedule] | IT/Legal | ___ | ___
9. Children's data | Age-gating, parental consent if applicable | ___ | [Implementation docs] | Product | ___ | ___
10. Cross-border transfers | Documented, compliant destinations only | ___ | [Transfer records] | Legal/IT | ___ | ___
11. DPO appointed (SDF) | Named, registered, India-based | ___ | [Appointment letter] | Board | ___ | ___
12. Annual audit (SDF) | Independent auditor engaged | ___ | [Audit report] | Board/DPO | ___ | ___
13. DPIA (SDF) | Conducted for all high-risk processing | ___ | [DPIA register] | DPO | ___ | ___

Getting Started

These templates give you the documents. ComplyDP's free Readiness Scan tells you which ones you actually need and where your gaps are. Start at complydp.com/scan - it takes under 10 minutes, covers all 43 DPDP controls, and requires no demo call or email.