# Data Protection Impact Assessment (DPIA)

**Aligned with DPDPA 2023, Section 10(2)(c)(i) and DPDP Rules 2025, Rule 13(1)–(2)**

---

## Document Control

| Field | Value |
|-------|-------|
| **System / Process Name** | |
| **DPIA Version** | 1.0 |
| **Date** | |
| **Prepared by** | |
| **DPO Review** | ☐ Pending ☐ Reviewed ☐ Approved |
| **CISO Approval** | ☐ Pending ☐ Approved |
| **Next Review Date** | *(review on every material DFD change; minimum annually)* |
| **Linked Threat Model** | `threat-model.yaml` v |

**Is this organisation a Significant Data Fiduciary (SDF)?**

☐ Yes — This DPIA is mandatory under Section 10(2)(c)(i) and Rule 13(1) (every twelve months)
☐ No — This DPIA is voluntary but recommended as Section 8(5) evidence

---

## Part A: Description of Processing

*Required by Section 10(2)(c)(i): "a description of the rights of Data Principals and the purpose of processing of their personal data"*

### A1. System Overview

**What does this system do?**

[Describe the system in 2-4 sentences. Focus on what happens to personal data: how it is collected, where it flows, where it is stored, and when it is erased.]

**Who operates this system?**

| Actor | DPDPA Role | Obligation |
|-------|------------|------------|
| [Your Company] | Data Fiduciary (S.2(i)) | Section 8 obligations; breach notification |
| [Processor A] | Data Processor (S.2(k)) | Rule 6(1)(f) DPA; operates under Fiduciary's instructions |
| [Processor B] | Data Processor | Rule 6(1)(f) DPA |

### A2. Purposes of Processing

*All purposes must have a lawful basis under Section 6(1). List each purpose separately.*

| Purpose ID | Purpose Label | Lawful Basis | DPDPA Section | Retention Period | Retention Anchor |
|------------|--------------|--------------|---------------|-----------------|-----------------|
| P01 | | Consent | S.6(1) | | S.8(7) + Rule 8(3) |
| P02 | | | | | |

### A3. Categories of Personal Data

| Data Category | Operational sensitivity¹ | Sections Affected | Examples |
|--------------|--------------------------|-------------------|---------|
| Contact identifiers | Standard | S.2(t), S.8(5) | Email, phone number |
| Financial data | High | S.2(t), S.8(5) | Account number, income |
| Health data | High | S.2(t), S.8(5) | Diagnosis, prescription |
| Biometric data | High | S.2(t), S.8(5) | Fingerprint, face scan |
| Behavioural data | Standard | S.6(1), S.8(5) | Click patterns, location |
| Children's data | Highest | S.9(1)–(3) | Any data of persons under 18 |

> ¹ DPDPA 2023 does not create a statutory "sensitive personal data" category. All personal data is governed uniformly by Section 8(5) "reasonable safeguards." Section 9 applies to children's data (persons under 18) and, under 9(1), to persons with disability who have a lawful guardian. Section 10 and Rule 13 add obligations for Significant Data Fiduciaries notified by the Central Government. The "Operational sensitivity" column reflects engineering risk classification, not a DPDPA legal distinction.

**Categories applicable to this system:**

- [ ] Contact identifiers
- [ ] Financial data
- [ ] Health data
- [ ] Biometric data
- [ ] Behavioural / tracking data
- [ ] Children's data (triggers Section 9 obligations)
- [ ] Cross-border transfer (triggers Section 16 obligations)

### A4. Data Principals

**Estimated count of Data Principals:** _______________

*(Neither the Act nor the Rules set a numeric SDF threshold. The Central Government notifies SDFs under Section 10(1) on factors including the volume and sensitivity of personal data processed; a large count is a reason to monitor for notification.)*

**Vulnerable groups:**
- [ ] Children (under 18) — Section 9 applies: verifiable parental consent (9(1), Rule 10), no detrimental processing (9(2)), no tracking, behavioural monitoring or targeted advertising (9(3))
- [ ] Persons with disability who have a lawful guardian — verifiable consent of the guardian (Section 9(1), Rule 11)
- [ ] No specific vulnerable groups

### A5. Data Flows (Summary)

*Reference your annotated Data Flow Diagram. The DFD should show all DPDPA actor types, lawful bases, purpose tags, trust boundaries, and retention clocks per the conventions in `dfd-annotation-guide.md`.*

**DFD document:** [link or path]

**Cross-border data flows:**

| Destination Country | Restricted by S.16(1) notification? | Stricter sectoral law (S.16(2)) | DPDPA Section |
|---------------------|-----------------------------------|-------------------------------|---------------|
| | ☐ No ☐ Yes (transfer blocked) | | S.16 |

---

## Part B: Rights of Data Principals

*Required by Section 10(2)(c)(i): "a description of the rights of Data Principals"*

### B1. Notice (Section 5; Rule 3)

How does the system provide Data Principals with notice of processing?

| Obligation | Implementation | Language Coverage | Status |
|------------|---------------|------------------|--------|
| Notice before/at collection (S.5(1)) | | | ☐ Implemented ☐ Gap |
| Notice in clear and plain language (Rule 3(b)) | | | ☐ Implemented ☐ Gap |
| Option to access notice in English or any Eighth Schedule language (S.5(3)) | | [List languages] | ☐ Implemented ☐ Gap |

### B2. Right of Access and Correction (Sections 11, 12)

| Obligation | Mechanism | SLA | Status |
|------------|-----------|-----|--------|
| Access to own personal data (S.11) | | | ☐ Implemented ☐ Gap |
| Correction of inaccurate data (S.12) | | | ☐ Implemented ☐ Gap |
| Erasure on withdrawal / purpose completion (S.8(7)) | | | ☐ Implemented ☐ Gap |
| Grievance redressal (S.13) | | Not exceeding 90 days (Rule 14(3)) | ☐ Implemented ☐ Gap |
| Nomination right (S.14) | | | ☐ N/A ☐ Implemented |

### B3. Right to Withdraw Consent (Section 6(4)–(6))

How does the system handle consent withdrawal?

- **Withdrawal mechanism:** [e.g., account settings toggle, API endpoint /consent/withdraw]
- **Cascade deletion trigger:** [e.g., async job deletes related records within 24h]
- **Proof-of-consent retention:** [e.g., consent event hash retained for 7 years; personal data cryptographically erased]
- **Burden of proof standard:** [describe how Fiduciary proves consent without retaining PII]

---

## Part C: Risk Assessment and Management

*Required by Section 10(2)(c)(i): "assessment and management of the risk to the rights of the Data Principals"*

### C1. Methodology

This DPIA uses the **LINDDUN + STRIDE** methodology to enumerate privacy and security threats per Data Flow Diagram element. The full threat catalog is in `threat-model.yaml`. This section summarises the findings by risk level.

**LINDDUN categories assessed:** Linkability, Identifiability, Non-repudiation, Detectability, Disclosure, Unawareness, Non-compliance

**STRIDE categories assessed:** Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege

### C2. Risk Matrix Summary

*Derived from threat-model.yaml — regenerate using the pipeline/threat-model-gate.yml before each DPO review.*

| Finding ID | DFD Element | Framework | Category | Severity | Mitigation Status | DPDPA Section |
|------------|-------------|-----------|----------|----------|------------------|---------------|
| L-01 | | LINDDUN | Linkability | High | ☐ Open ☐ Mitigated ☐ Accepted | |
| L-02 | | LINDDUN | Identifiability | High | ☐ Open ☐ Mitigated ☐ Accepted | |
| L-03 | | LINDDUN | Non-repudiation | Medium | ☐ Open ☐ Mitigated ☐ Accepted | |
| L-04 | | LINDDUN | Detectability | Medium | ☐ Open ☐ Mitigated ☐ Accepted | |
| L-05 | | LINDDUN | Disclosure | Critical | ☐ Open ☐ Mitigated ☐ Accepted | |
| L-06 | | LINDDUN | Unawareness | High | ☐ Open ☐ Mitigated ☐ Accepted | |
| L-07 | | LINDDUN | Non-compliance | High | ☐ Open ☐ Mitigated ☐ Accepted | |
| S-01 | | STRIDE | Spoofing | High | ☐ Open ☐ Mitigated ☐ Accepted | |
| S-02 | | STRIDE | Tampering | Critical | ☐ Open ☐ Mitigated ☐ Accepted | |
| S-03 | | STRIDE | Repudiation | High | ☐ Open ☐ Mitigated ☐ Accepted | |
| S-04 | | STRIDE | Information Disclosure | High | ☐ Open ☐ Mitigated ☐ Accepted | |
| S-05 | | STRIDE | Denial of Service | Medium | ☐ Open ☐ Mitigated ☐ Accepted | |
| S-06 | | STRIDE | Elevation of Privilege | High | ☐ Open ☐ Mitigated ☐ Accepted | |

**Summary counts:**

| Severity | Open | Mitigated | Accepted |
|----------|------|-----------|---------|
| Critical | | | |
| High | | | |
| Medium | | | |
| Low | | | |

### C3. Open Findings Requiring DPO Decision

List any findings not yet mitigated that require DPO or Board decision.

| Finding ID | Description | Proposed Treatment | Decision Required By |
|------------|-------------|-------------------|---------------------|
| | | Accept / Mitigate / Transfer | |

### C4. Residual Risks Accepted

| Finding ID | Residual Risk Description | Rationale for Acceptance | Accepted By | Date |
|------------|--------------------------|--------------------------|-------------|------|
| | | | | |

---

## Part D: Consultation

*Section 10(2)(c)(i) allows further matters to be prescribed by rules. Rule 13(2) requires the person carrying out the DPIA and audit to furnish the Board a report containing significant observations.*

### D1. Internal Consultation

| Stakeholder | Consulted | Date | Outcome |
|-------------|-----------|------|---------|
| DPO | ☐ Yes ☐ No | | |
| CISO | ☐ Yes ☐ No | | |
| Legal Counsel | ☐ Yes ☐ No | | |
| Engineering Lead | ☐ Yes ☐ No | | |
| Product Manager | ☐ Yes ☐ No | | |

### D2. Data Processor Consultation

| Processor | DPA in Place | DPA Reference | Rule 6(1)(f) Obligations Confirmed |
|-----------|-------------|---------------|-----------------------------------|
| | ☐ Yes ☐ No | | ☐ Yes ☐ No |

---

## Part E: Conclusion and Recommendations

### E1. Overall Assessment

☐ **Approved** — No residual risks above Medium severity; all open findings have mitigations in progress with delivery dates.

☐ **Approved with conditions** — [List conditions]

☐ **Escalate to Board** — Critical or High findings without accepted mitigations. System should not go to production until resolved.

### E2. Recommendations

| # | Recommendation | Priority | Owner | Target Date |
|---|---------------|----------|-------|-------------|
| 1 | | Critical / High / Medium | | |

### E3. Next Review Trigger

This DPIA must be reviewed when:
- [ ] A new personal data field is added to any DFD element
- [ ] A new purpose of processing is introduced
- [ ] A new Data Processor boundary is created
- [ ] A cross-border transfer is added or the destination country changes
- [ ] A personal data breach occurs (Section 8(6))
- [ ] The Rules are amended or the Board issues a direction affecting this processing
- [ ] 12 months have elapsed since the last review

---

## Part F: Sign-Off

| Role | Name | Signature | Date | Decision |
|------|------|-----------|------|---------|
| **Data Protection Officer** | | | | ☐ Approved ☐ Escalate |
| **CISO** | | | | ☐ Approved ☐ Escalate |
| **Engineering Lead** | | | | ☐ Approved ☐ Escalate |
| **Legal Counsel** | | | | ☐ Approved ☐ Escalate |

---

## Appendix: Regulatory References

| Obligation | Source | Summary |
|-----------|--------|---------|
| DPIA mandatory | DPDPA 2023, Section 10(2)(c)(i) | Significant Data Fiduciaries must conduct DPIAs |
| Reasonable safeguards | DPDPA 2023, Section 8(5) | All Fiduciaries must take reasonable security safeguards |
| DPIA includes risk assessment | Section 10(2)(c)(i) | "assessment and management of the risk to the rights of the Data Principals" |
| SDF additional measures | DPDP Rules 2025, Rule 13(1)–(3) | Annual DPIA and audit; report of significant observations to the Board; due diligence on algorithmic software |
| Security minimum floor | DPDP Rules 2025, Rule 6(1)(a)-(g) | Encryption, access controls, logging and monitoring, backups, one-year log retention, processor contracts, technical/organisational measures |
| Erasure obligation | DPDPA 2023, Section 8(7) | Erase personal data when purpose is complete |
| Consent proof | DPDPA 2023, Section 6(10) | Fiduciary must be able to demonstrate consent was given |