Chapter 20 — Privacy Risk Assessment and Impact Assessments

1. The document that convinces nobody

Two failure patterns illustrate why an impact assessment can become unhelpful. The first is the shelf-filler: a comprehensive, beautifully-structured document produced once for a launch, filed, and never opened again — its risk sections still describing an estate that has since been re-platformed twice. The second is the box-tick: a two-page form whose every field reads “low,” whose mitigations column says “existing controls,” and whose signature block is the only part anyone reads.

Both fail the same test: neither is a decision record. A shelf-filler records a moment; a box-tick records a mood. Neither tells the enterprise — or a Board, or an auditor — what was assessed, what was decided, and on what basis, which is the only thing an impact assessment exists to do.

DPDP makes this discipline statutory for a specific class, and its text is worth reading before the method:

Section 10(2)(c)(i) describes a periodic DPIA comprising the purposes and principals’ rights and the assessment and management of risks to those rights (ACT:430–438).[1] The statutory duty is SDF-specific. A non-SDF may use this method voluntarily without calling it a DPDP DPIA mandate. Technical and security risks belong in the assessment wherever they can harm those rights; the distinction is the affected person, not the department that owns the control.

Start with the person affected. Unauthorised access can expose her records; a stale input can produce an adverse decision; a withdrawal lost between systems can permit continued unwanted use. The assessment should connect each mechanism to the relevant duty and to evidence, rather than attach the word “rights” to an otherwise unchanged enterprise loss model. Broader welfare or explainability concerns may be assessed as author-recommended risk dimensions without inventing a DPDP right to a particular model explanation.

The idea. A DPIA is a living decision record: a documented description of purposes and affected rights, a reasoned assessment of the risks to those rights, a selected mitigation set, and a recorded decision — re-run on a defined schedule and on every material change. Its quality is not its length; it is whether a stranger (an auditor, a Board, a successor) can reconstruct why the enterprise decided this processing was acceptable on this evidence at this date — and whether the record is current enough that the reconstruction still matches reality.

2. The tension: comprehensiveness versus actionability

A scoped assessment can be short without being empty. The practical failure is missing reasoning or evidence, not page count. Conversely, a large assessment can become costly to maintain when every local change requires rewriting the whole estate description. Scope creep is therefore a third failure mode: the document covers so much that its owners cannot tell which decisions a change invalidates.

The recommended response is trigger-defined scope with a consistent method. Identify the changed model, purpose, processor or affected population; retain the relevant interfaces to other assessments; then repeat description, risk analysis, mitigation and decision. This is the book’s operating design, not a claim that the word “periodic” prescribes this exact document structure. The following method shows what must remain visible even in a concise assessment.

3. The method

The method begins with a legal-permissibility gate and then follows five recorded steps. Before estimating residual risk, identify the actor, applicable provisions and commencement, intended purpose and ground, child restrictions, relevant exemptions and any unresolved facts. A prohibited purpose, absent ground, or unsubstantiated exception is a stop or re-scope decision. A business signature cannot make it lawful (ACT:160–166,216–224,386–403).[1]

Scope. Identify the model, purpose change, new data class or flow being assessed, and the affected population. Draw from the inventory and purpose matrix, but do not wait for a perfect whole-estate inventory to assess or contain an already known harmful flow. Record what is unknown, restrict the affected launch, and investigate in parallel. Scope exclusions need reasons and an owner.

Scope is also where the rights framing becomes concrete. The scope does not merely list the processing activities; it lists the rights those activities engage. A new lending model engages the principal’s access right (she may want to know what data informed the decision), her correction right (she may want to correct an inaccurate input), and her erasure right (she may want the model’s feature store deleted). These rights are the assessment’s organising principle, not the processing activity — because the Act’s language asks what risk the processing poses to the principal’s rights, not what risk the processing poses to the enterprise.

Describe. The statutory content, made concrete: the purposes of the processing, the data involved, and — Section 10(2)(c)(i)‘s distinctive demand — the rights of the Data Principals the processing touches. Not “the data flows from A to B,” but “this processing engages the principal’s access right, her correction right, her consent and its withdrawal” — the rights framing that pulls every downstream chapter into the assessment. The description must be sufficient for a stranger to understand what the processing does, what data it uses, what rights it affects, and why the enterprise considers the processing necessary — not because the Act requires a necessity justification in the DPIA (it does not), but because the risk assessment that follows cannot be reasoned without understanding the processing’s purpose.

Assess risk. Risk to those rights, reasoned: for each engaged right, what could go wrong for the principal — decisions on inaccurate data (Section 8(3)), processing beyond the consented purpose, monitoring reaching children, erasure that misses derived copies — with likelihood and impact honestly judged. The Chapter 6 scenario instinct applies: bands and factors, not false precision.

The risk assessment is not a spreadsheet of numerical scores. It is a reasoned argument: for each right, what could go wrong, how likely it is, how severe the impact on the principal would be, and what evidence supports the judgement. The likelihood and impact judgements are qualitative — real, possible, unlikely; high, moderate, low — not fabricated percentages. The point is not to produce a number; the point is to produce a reasoned assessment that a stranger can read, understand, and agree or disagree with. A risk assessment that cannot be disagreed with is not honest; it is opaque.

The risk-to-rights framing requires a specific discipline: the assessment must distinguish between risk to the enterprise and risk to the principal. A data breach is a risk to both, but the assessment’s statutory framing is the principal’s risk — the harm to the principal from the breach, not the cost to the enterprise. An inaccurate credit decision is a risk to the principal (a refused loan), not just a risk to the enterprise (a regulatory finding). The distinction is not academic; it determines what gets assessed and what gets mitigated. A risk assessment that evaluates only enterprise risk will miss the principal harms that the Act requires the SDF to assess.

Mitigate. The control planes mapped to each risk — purpose-bound access, registry, deletion reach, child-guard — with each mitigation named as a tested control (Ch.22) or flagged as residual. A mitigation that is a control name without a test result is the box-tick hiding inside the DPIA. The mitigation step is where the assessment meets the programme’s actual controls: each named mitigation must correspond to a real control with a real test result, or it must be flagged as residual uncertainty that is eligible for business review only after the legal-permissibility gate. A failed or absent mandatory control cannot be renamed “accepted risk”. A passing test supports the tested mechanism, not elimination of all harm. The record should say what remains uncertain and how that uncertainty constrains use.

The mitigation step also requires the assessment to consider whether the control is sufficient, not merely whether it exists. A purpose-bound access control that exists but has not been tested for the specific processing being assessed is a mitigation in name only. The assessment must ask: does this control address the specific risk I have identified? Is it designed for this processing? Has it been tested in this context? The answer may be “yes, and the test result is green” or “partially, and the residual risk is documented” — but it must be an answer, not a label.

Decide and document. Stop/reject, re-scope, mitigate-before-proceeding, or proceed within a lawful bounded scope. Record the accountable business sponsor, legal advice, DPO/privacy challenge, evidence and date. A condition precedent is not an approval to run before it is met. Then record the scheduled review and early-reopening triggers.

The decision is not a formality. It is the assessment’s conclusion: given the risks identified, the mitigations available, and the residual risk accepted, does the enterprise proceed with this processing? The decision-maker must be named and the evidence must be cited — because the decision is the point where accountability attaches. The auditor will ask not just “what were the risks?” but “who decided this was acceptable, and on what basis?” The decision step is the answer.

The trigger log is the assessment’s promise to stay current. It specifies: the prescribed cadence (for the SDF, the Rule 13 cycle; for the voluntary adopter, the chosen schedule); the material changes that re-open the assessment early; and the date of the next scheduled review. An assessment without a trigger log is an assessment that will not be re-run — which is the shelf-filler’s seed.

4. Triggers and schedule

For the SDF: Rule 13(1) requires DPIA and audit once in each twelve-month period from notification or inclusion in a notified class. Rule 13(2) requires the SDF to cause the person carrying them out to furnish significant observations to the Board (RULES:1276–1282).[5] The book recommends a portfolio of scoped assessments reconciled against the entire applicable processing estate. This is an implementation method, not a required statutory document format. A portfolio must not lose system-wide risks at the boundaries between units.

Material-change triggers, recommended between cycles: new high-risk processing, purpose or ground; changed data or population; processor or cross-border route; altered model/technical measure; designation or a changed applicable instrument. Track each event, accountable assessor and disposition. These triggers help maintain effective controls; they are not a verbatim statutory list or a replacement for the twelve-month cycle. Rule 13(3)‘s due diligence covers the listed technical measures including algorithmic software, not only models presumed to cause “significant effects” (RULES:1283–1286).[5]

For the non-SDF, voluntarily: the same method applied to genuinely high-risk processing — and honestly labelled. A voluntary DPIA is good practice this book recommends; it is not a statutory duty for the non-SDF, and presenting it as one imports the GDPR’s Article-35 habits into a regime that structured the duty differently (Ch.3’s transplant warning, at the assessment layer). The voluntary adopters should choose their own cadence, define their own triggers, and label the assessment honestly: “voluntary DPIA per the method in Chapter 20, not a statutory requirement.” The label protects the enterprise from creating an expectation of statutory compliance where none exists, and it protects the method from being diluted by enterprises that treat it as a compliance exercise rather than a discipline.

A scoped portfolio reduces maintenance effort where units have clear boundaries, but one cross-cutting assessment may be better for a tightly coupled service. Use a shared inventory, a common legal-permissibility gate and explicit dependencies so separate documents do not miss a shared identity service, restore path or processor. The reviewer should be able to explain both coverage and exclusions, not merely count files.

5. Risk to rights: the assessment’s distinctive framing

The risk assessment’s focus on risk to rights is not a semantic preference; it is the Act’s structural demand, and it produces a different assessment from a business-impact or technology-risk analysis. The difference is worth making explicit, because most enterprises will reach for familiar risk frameworks and find that they assess the wrong thing.

A business-impact assessment may estimate response cost; a security assessment may identify an exploitable privilege; the DPIA should carry the resulting principal harm through to a decision. These are complementary analyses. A compromised warehouse reader can disclose identifiable features, defeating confidentiality even when the purpose tag is correct. Purpose-bound access and underlying authentication, authorisation, encryption, logging and recovery controls all belong in the DPIA when they address that harm (ACT:338–347; RULES:1087–1108).[1][5]

For a lending model, distinguish accuracy of the personal data from model calibration or discrimination. Section 8(3) concerns completeness, accuracy and consistency where data is likely to be used for a decision affecting the principal or disclosed to another fiduciary (ACT:338–342).[1] An assessment can also ask whether affected people understand and can challenge a decision, but should label added explanation/human-review safeguards as recommendations or separately sourced sector requirements. Sections 11 and 12 concern specified access and correction/erasure rights within prior-consent scope, including Section 7(a); they do not promise every internal model detail (ACT:441–476).[1]

6. Residual-risk analysis and approval authority

Every DPIA will identify risks that are not fully mitigated — risks where the available controls reduce but do not eliminate the harm to the principal, or where the cost of further mitigation exceeds the benefit. These are residual risks, and the assessment must name them explicitly.

The residual-risk step is where honesty matters most. A DPIA that lists every risk as “mitigated” is a box-tick, regardless of its length. A DPIA that names its residual risks — “the model’s explainability to the principal is not fully addressed by existing controls; the residual risk is documented and accepted by [name], [date]” — is an honest record. The residual risk is not a failure of the assessment; it is the assessment’s most important output, because it tells the enterprise (and the auditor) where the gaps are.

The accountable business sponsor owns the processing decision and resources. The DPO or privacy lead advises and challenges; legal counsel assesses permissibility and unresolved application. The governing body handles escalations under the chosen governance policy. Independence of advice should not be lost by making the DPO both designer and sole risk acceptor. Record the actual authority and any dissent, not a generic “privacy approved” badge.

Stop conditions include missing purpose-specific authority, prohibited child targeting, untested controls on which permissibility depends, an unresolved mandatory transfer restriction, and a known bypass capable of continuing the prohibited use. These are operating gates in this method; they do not set a numerical legal safe harbour. Once lawfulness is established, the sponsor may assess bounded uncertainty, with expiry and monitoring, but not waive an applicable duty.

The residual-risk register is also the input to the enterprise’s wider risk management. Each residual risk identified in a DPIA should flow to the Chapter 6 dashboard and the Chapter 24 risk register — not as a privacy-specific concern, but as a risk to the enterprise’s compliance posture that the wider governance must see. The DPIA does not own the residual risk; it identifies it. The enterprise’s governance owns the decision to accept it.

7. The independent review

Section 10(2)(b) requires an independent data auditor to evaluate SDF compliance; it does not specify that every individual DPIA requires an auditor signature as a pre-launch approval (ACT:427–438).[1] This book recommends independent challenge of each consequential assessment, with that work available to the statutory auditor where applicable. Separate the author, business decision-maker, challenger and auditor roles. As Chapter 19 explains, stricter supplier separation is a procurement safeguard; the retained Act does not supply an absolute same-firm rule.

The independent review is not a rubber stamp. It is a substantive examination of the assessment’s quality, and its output is a set of comments that must be addressed — not necessarily accepted, but addressed. The reviewer’s comments and the assessment author’s responses become part of the record, because they demonstrate that the assessment was challenged and either improved or defended.

A review with no comments is not automatically fictitious. It still needs scope, work performed and a reasoned conclusion; a long comment list is not proof of quality either. The record should preserve material disagreements, responses and unresolved qualifications.

For the voluntary adopter, the independent review is not a statutory requirement, but it is the method’s integrity check and should not be skipped. Self-review cannot supply independent challenge. An internal reviewer from a different function may provide it where competence and conflicts are addressed; an external reviewer is useful when additional expertise or separation is needed, not automatically better merely because the reviewer is external. The method’s integrity does not depend on whether the review is statutory; it depends on whether the review is genuinely independent.

8. The control-test-evidence set

9. Two worked walkthroughs

Common assumptions. The worked records below are synthetic and use the fixed dossier, not unsupplied client telemetry. out/remediation/Q05/dpia.md is the populated DPIA-PACK-001 fragment and dpia-decisions.json is its structured companion. No board approval, real consent grant, independent audit or production launch occurred. They assume the retained scheduled provisions commence unchanged.

Walkthrough one — DPIA-001 refuses the combined proposal. On EVT-023 the Company’s sponsor proposes training in SYS-005 on DS-006 and adding a child-targeted campaign. PUR-003 has no grant in the base case; DEC-001 therefore remains stop. PUR-011 is the CASE-101 child-targeting counterexample, involving SUB-004; no applicable exception is established and a claimed parent token does not remove Section 9(3)‘s separate restriction (ACT:386–403; RULES:1269–1275).[1][5] The Company is not silently changed into a retailer: the assessment explicitly rejects extending its proposal to the separate retail child campaign. The combined launch is refused, not approved subject to an eventual age refresh.

The security-risk row identifies a warehouse export path that could bypass the serving gate. Its harm is disclosure and continued unauthorised reuse, not merely an enterprise security score. Its required mitigation is scope-bound export authorisation with route evidence. The accuracy row identifies incomplete inputs as a proposed negative test; it does not claim that a real bureau feed was observed truncated. The legal gate decides before any residual scoring: neither model value nor a low expected complaint rate supplies missing training authority.

Re-scope separates three decisions. Training remains off. Child targeting remains off. Adult serving under PUR-004 can be evaluated only with its own necessity, authority, data-quality and route controls; it cannot inherit PUR-003 consent or the fact that a model was built previously. The sponsor records resources for this narrower review, the privacy adviser records the objection, and no person signs the prohibited proposal into acceptance. The local model tests exercise refusal and separate-purpose logic, not model accuracy or a deployed lending service.

Walkthrough two — a lawful exception is narrow, not a risk waiver. CASE-103 / ENT-103 is a separate fictional educational institution. DEC-003 addresses PUR-013: tracking/behavioural monitoring limited to educational activities or safety of enrolled children. Fourth Schedule Part A item 3, through Rule 12, conditionally disapplies Section 9(1) and (3); it does not remove Section 9(2)‘s detrimental-effect bar or authorise commercial advertising (RULES:1682–1707; ACT:386–403).[5][1] In the specimen the institution/class, enrolment, educational-or-safety-only purpose and no detrimental-effect facts are explicitly stipulated, not verified for a real school. Authority for the remaining processing requirements is separately reviewed; exemption from two child clauses is not a new general ground. The conditional decision permits only that restricted scope when every recorded condition holds.

Change the recipient to an advertising processor or the use to commercial targeting and the exception fails. The decision then returns stop, even with parental permission. This is the important contrast: a lawful exception is established from eligible facts and source text; “accepted residual risk” cannot manufacture those facts. The local negative test changes the purpose and rejects it. It does not certify an educational product or determine that learning models are universally harmless.

Recovery and reopening. The assessment keeps rejected scope, later evidence and revised decisions as distinct versions. It may reopen training only after a new lawful-ground decision and evidence for the intended data and processing. It may reopen child use only on an applicable source-backed exception, not a renamed product. A revised record must not retroactively turn a refused launch into one that was approved at the time. The borrower remains SUB-001 in rights and erasure records; nominee or reviewer identity never replaces the subject.

10. The DPIA template as deliverable

The method above produces a structured assessment, and the structure can be captured in a template that every assessment follows. The template is not a form to fill in; it is a decision record to construct, and its sections correspond to the method’s steps:

1. Identification: Assessment ID, date, assessor, scope (processing activities, data classes, rights engaged).
2. Scope decision: What is in, what is out, and why.
3. Description: Purposes, data, rights engaged, and the nexus between them.
4. Risk assessment: For each engaged right, the risk, its likelihood and impact, and the reasoning.
5. Mitigation: For each risk, the control(s) that address it, with test status.
6. Residual risk: For each risk not fully mitigated, the residual, its acceptance authority, and the date.
7. Decision: Stop/reject, re-scope, mitigate-before-proceeding, or lawful bounded proceed; business authority, legal advice, privacy challenge, evidence and expiry.
8. Independent review: Reviewer, comments, and resolution.
9. Trigger log: Prescribed cadence, material-change triggers, next review date.

The template supplies required questions, not automatic completeness. The populated fragment shows the refused branch and a conditional exception; it is deliberately not a blank form presented as an exercised deployment. When adapting it, replace each stipulated fact with evidence, identify the actual decision authority and test the boundaries that could reverse the result.

11. What remains for the reader and the reviewer

The open items, each <residual>:

1. Actual SDF applicability and cycle anchor — the retained Rule 13 twelve-month cadence is settled; the entity’s notification and transition facts are not supplied.
2. Entity-specific coverage and evidence — no statutory DPIA form is identified in the retained Rule 13 passage; any later or sector-specific format must be checked before use.
3. Non-SDF overlays — voluntary under this DPDP SDF provision does not exclude a separate applicable sector or contractual assessment duty.
4. Eligible residual-risk policy — business governance sets bounds for lawful uncertainty; it cannot defer the stop conditions above to a future counsel exercise.
5. Technical measures and specified data — the Rule 13(3)/(4) rows are completed in Chapter 19; actual measures, restrictions and route evidence require entity-specific review (RULES:1283–1290).[5]

The question that hands the book its next chapter

Chapter 21 next applies the assessment to AI, analytics, profiling and derived data: how separate training and serving purposes, identifiable outputs and changed authority alter the design. Chapter 22 then supplies the testing and evidence discipline used to check the resulting controls.

References (sources retained)

• DPDP Act 2023 — research/legal/evidence/01_dpdp_act_2023_gazette.txt (Section 10).
• DPDP Rules 2025 (GSR 846(E)) — research/legal/evidence/05_gsr_846e_dpdp_rules_2025.txt (Rule 13).
• Research, re-anchored not reused: data_protection_impact_assessment.md and gdpr_article_35_per_phase_dpia.md — the C/D-graded GDPR seeds whose structure informed the method and whose legal frame was discarded.
• Chapters 7/8 (the inventory and matrix the scope joins on), 19 (the SDF envelope this cycle belongs to), 21 (the model walkthrough this chapter re-ran), 22 (the evidence every mitigation cites), 36 (the trigger loop that feeds the queue).

Source keys and evidence limits

Line locators use newline-based retained text, not PDF page numbers. Primary sources were reread locally; no complete live legal-update search or entity-specific opinion is asserted. Vendor passages are documented claims, not observed capabilities.

• COMM: research/legal/evidence/02_gsr_843e_commencement.txt.
• RULES: research/legal/evidence/05_gsr_846e_dpdp_rules_2025.txt.
• CORR: research/legal/evidence/06_gsr_892e_corrigendum.txt.
• ACT: research/legal/evidence/01_dpdp_act_2023_gazette.txt.

Sources

[1] https://www.meity.gov.in/static/uploads/2024/06/2bf1f0e9f04e6fb4f8fef35e82c42aa5.pdf — Digital Personal Data Protection Act, 2023 (Act No. 22 of 2023) [2] https://www.meity.gov.in/static/uploads/2025/11/c56ceae6c383460ca69577428d36828b.pdf — G.S.R. 843(E), DPDP Act commencement notification [5] https://www.meity.gov.in/static/uploads/2025/11/53450e6e5dc0bfa85ebd78686cadad39.pdf — Digital Personal Data Protection Rules, 2025, G.S.R. 846(E) [6] https://www.meity.gov.in/static/uploads/2025/12/3c7ebbae0e5456f493f486e6845df86b.pdf — Corrigenda to G.S.R. 846(E), G.S.R. 892(E)

Contents · Reader guide and citation conventions · Artifact index