A useful data protection impact assessment starts with the workflow

A risk spreadsheet is easier to complete when the team understands the activity it is assessing. Without that understanding, a DPIA can become a list of generic risks and familiar controls that never tests the actual product decision.

Under DPDP, periodic DPIAs are an additional requirement for Significant Data Fiduciaries, with detail in section 10 and rule 13. As of 22 October 2026, those substantive provisions are scheduled for May 2027 under the commencement notification. Other organisations can use the method voluntarily; this article does not claim every business has a universal statutory DPIA duty.

Choose a bounded processing journey

Consider a hypothetical lending-support service proposing a tool that ranks applications for manual review. Start with one application: what information enters, where it comes from, what the tool produces, who sees the result and what happens to the applicant afterwards.

Include exceptions. What happens when data is missing, a record is wrong or a person challenges the result? Who can override the output? Does a vendor retain inputs or use them for another purpose? These questions describe the workflow before anyone assigns a risk score.

Draw a small map and validate it with the people operating the service. A diagram made only from a supplier brochure may omit exports, human workarounds or a second system that actually determines the outcome.

Describe consequences for people

Section 10(2)(c)(i) describes a DPIA in terms that include rights, processing purposes and assessment and management of risks to those rights. Ask how the workflow could affect an individual, rather than limiting the discussion to financial loss for the company.

For the application-ranking example, an incorrect identity match might attach another person’s information. A poorly explained data source might make correction difficult. Excessive access could expose financial details to staff who do not need them. A ranking error might delay review even where a human makes the final decision.

These are hypothetical risk scenarios, not findings about a particular product. The assessment should distinguish plausible risk from evidence of an actual failure and identify what information is needed to judge each scenario.

Compare alternatives before adding controls

Ask whether the purpose can be achieved with fewer data items, a shorter retention period, less identifiable information or a different decision process. A control that protects unnecessary data does not answer why the information was collected in the first place.

The service might remove a weakly relevant field, limit vendor retention or change how uncertain cases are routed for human review. Each option has practical trade-offs. Record the reason for the selected design and the consequences of rejecting another option.

Avoid assuming that a human reviewer automatically removes risk. The reviewer may have little time, insufficient information or a habit of accepting the tool’s output. Assess the actual review procedure and evidence of its operation.

Tie safeguards to the scenario

For each material risk, identify the proposed safeguard, owner, evidence and remaining uncertainty. An identity-matching risk might need better source verification and a correction route. An access risk might need role-based permissions and periodic review. A retention risk might need a lifecycle rule and vendor confirmation.

Do not write “encryption” beside every risk. Encryption can protect information in defined circumstances, but it does not make an inaccurate record correct or a purpose transparent. The assessment should explain how the safeguard changes the relevant likelihood or consequence.

Choose a scoring method only if it helps comparison. The final DPDP provisions do not prescribe a universal five-by-five matrix or vendor risk score. A clear qualitative explanation can be more useful than a precise-looking number built on unsupported assumptions.

Make approval conditional where necessary

Present unresolved issues to the decision-maker. Specify whether the activity can proceed, needs modification or should wait for missing evidence. If approval depends on a control being implemented, verify that condition before the relevant processing begins.

For SDFs, rule 13 connects the DPIA and audit to a recurring twelve-month cycle and reporting of significant observations. A launch assessment should therefore fit a continuing review process rather than disappear into a project folder.

Revisit the assessment when purposes, data sources, vendors or decision logic change. The most useful DPIA is a record of how the team understood the workflow, evaluated consequences and chose a design. Its value comes from the decisions it changes and the evidence it can later be tested against.