A product team ships a new onboarding flow, the security team approves the vendor, and legal updates the privacy notice three weeks later. The risk is not that nobody cared about privacy. The risk is that no one can show, in one place, how the data flow, purpose, controls, vendors, and Data Principal rights were reviewed before launch.

Under the Digital Personal Data Protection Act, 2023, that review becomes mandatory for a specific class of organizations: Significant Data Fiduciaries.

Section 10(2)(c)(i) of the Digital Personal Data Protection Act, 2023 requires a Significant Data Fiduciary to undertake a periodic Data Protection Impact Assessment, and Rule 13 of the Digital Personal Data Protection Rules, 2025 turns that into a once-in-twelve-months DPIA and audit obligation.

The practical answer is narrower and more useful than most PIA DPIA India explainers suggest: a DPIA is legally required under DPDPA when your organization is notified as a Significant Data Fiduciary, but a PIA-style review should be run before high-risk processing changes even if you are not yet formally designated.

The legal obligation may start with designation. The evidence problem starts much earlier.

‍

Quick answer: when is a PIA or DPIA required in India?

For DPDPA purposes, the statute uses Data Protection Impact Assessment, not a separate PIA/DPIA distinction. In operating language, teams often call the same review a PIA, privacy risk assessment, or DPIA.

Here is the decision rule:

• Mandatory under DPDPA: if the Central Government notifies your organization, or your class of organizations, as a Significant Data Fiduciary under Section 10(1) of the Digital Personal Data Protection Act, 2023.
  ‍
• Timing for SDFs: Rule 13(1) of the Digital Personal Data Protection Rules, 2025 requires the SDF to undertake a Data Protection Impact Assessment and audit once in every twelve-month period from the date it is notified as an SDF or included in a notified SDF class.
  ‍
• Report trail: Rule 13(2) of the Digital Personal Data Protection Rules, 2025 requires the person carrying out the DPIA and audit to furnish the Board a report containing significant observations.
  ‍
• Not automatically mandatory for every Data Fiduciary: ordinary Data Fiduciaries still have general DPDPA obligations, but Section 10 is the specific DPIA hook for SDFs.
  ‍
• Still operationally necessary: run a PIA before high-risk launches, material product changes, large-scale profiling, children’s data workflows, health or financial data workflows, and processor-heavy workflows, because the assessment produces the evidence trail you will need later.

PIA vs DPIA in India: use the right term for the right audience

A Privacy Impact Assessment usually means an internal review of how a project, system, vendor, or process affects personal data. A Data Protection Impact Assessment is the term used in many legal regimes for a more formal risk assessment tied to rights, purposes, and safeguards.

Under DPDPA, the precise statutory term is Data Protection Impact Assessment. Section 10(2)(c)(i) of the Digital Personal Data Protection Act, 2023 describes it as a process comprising a description of the rights of Data Principals, the purpose of processing their personal data, an assessment of risk to those rights, and measures for managing those risks. That is the definition compliance teams should use when building the assessment template.

For internal workflows, “PIA” is still useful. It tells product, engineering, security, procurement, and legal that the review is not only a legal memo. It is a launch gate that asks whether the processing can be explained, limited, protected, and evidenced.

So the clean operating model is:

• call the statutory artifact a DPIA when referring to Section 10 and Rule 13;
  ‍
• use PIA for the earlier product or vendor review that may feed the formal DPIA;
  ‍
• keep both in the same system of record so evidence is not split across spreadsheets, ticket comments, and legal files.

‍

What Section 10 actually makes mandatory

Section 10 of the Digital Personal Data Protection Act, 2023 is about Significant Data Fiduciaries, not every organization that touches personal data.

Section 10(1) says the Central Government may notify any Data Fiduciary or class of Data Fiduciaries as significant based on relevant factors, including volume and sensitivity of personal data, risk to Data Principal rights, impact on India’s sovereignty and integrity, risk to electoral democracy, security of the State, and public order.

Once an organization is an SDF, Section 10(2) adds three governance duties:

• appoint a Data Protection Officer who is based in India and is responsible to the board or similar governing body;
  ‍
• appoint an independent data auditor to evaluate compliance with the Act;
  ‍
• undertake periodic Data Protection Impact Assessments and other prescribed measures.

The official Digital Personal Data Protection Act, 2023 text published by MeitY is the source to use for these section numbers. Do not rely on generic privacy summaries for statutory numbering.

The penalty context matters too. Under Section 33 and the Schedule to the Digital Personal Data Protection Act, 2023, breach of additional SDF obligations under Section 10 may attract a penalty up to ₹150 crore, while failure to take reasonable security safeguards to prevent a personal data breach may attract a penalty up to ₹250 crore.

Those figures are not scare copy. They are the ceiling figures in the statutory penalty schedule.

‍

What Rule 13 adds to the DPIA workflow

Rule 13 of the Digital Personal Data Protection Rules, 2025 makes the SDF obligation operational. It does three important things.

First, it sets the cadence. Rule 13(1) requires a Significant Data Fiduciary to undertake a Data Protection Impact Assessment and an audit once in every twelve-month period from the date it is notified as an SDF or included in a notified class.

Second, it creates a reporting path. Rule 13(2) requires the person carrying out the DPIA and audit to furnish to the Board a report containing significant observations from the DPIA and audit.

Third, it connects impact assessment to technical risk. Rule 13(3) requires an SDF to observe due diligence to verify that technical measures, including algorithmic software used for hosting, display, uploading, modification, publishing, transmission, storage, updating, or sharing of personal data, are not likely to pose a risk to the rights of Data Principals.

The Digital Personal Data Protection Rules, 2025 Gazette text on MeitY also states in Rule 1 that Rules 3, 5 to 16, 22, and 23 come into force eighteen months after publication in the Official Gazette. The Press Information Bureau’s DPDP Rules, 2025 explainer says the Rules were notified in November 2025 and describes the phased implementation approach.

As of 3 July 2026, compliance teams should track the Gazette commencement and any SDF notification separately, because the annual DPIA clock depends on SDF notification or class inclusion.

‍

When should a non-SDF still run a PIA?

A non-SDF may not yet have the formal Section 10 DPIA obligation. That does not make impact assessment optional as a governance practice.

The common wrong fix is to wait for a government notification and then build the DPIA workflow under pressure. By then, the product may already be live, vendor contracts may already be signed, data flows may already be undocumented, and deletion obligations may already be hard to execute.

Run a PIA before launch or material change when any of these triggers appears:

1. New personal data collection: a product, app, form, campaign, or support workflow starts collecting a new category of personal data.
   ‍
2. New purpose: the same data will be used for a different specified purpose, recommendation model, fraud workflow, or marketing workflow.
   ‍
3. Large-scale or sensitive-context processing: BFSI, healthcare, pharma, telecom, or HR workflows process data where misuse can materially affect individuals.
   ‍
4. Children’s data: the workflow may involve children, which brings Section 9 of the Digital Personal Data Protection Act, 2023 into the review.
   ‍
5. Automated or algorithmic decisioning: technical measures or algorithmic systems influence access, ranking, eligibility, fraud treatment, or user experience.
   ‍
6. Processor or vendor dependency: personal data moves to a new processor, SaaS tool, analytics system, call center, cloud service, or outsourced operations team.
   ‍
7. Retention or erasure change: a system keeps data longer, deletes it differently, or cannot prove erasure after withdrawal or purpose completion.
   ‍
8. Breach-impact concern: a failure in the workflow could create reportable harm or expose the organization to the security-safeguards obligation under Section 8(5) of the Digital Personal Data Protection Act, 2023.

A good internal threshold is simple: if the change affects what personal data is collected, why it is processed, who receives it, how long it is retained, how rights are exercised, or how the risk is controlled, run a PIA.

‍

What a DPDPA-ready PIA should contain

A weak PIA asks, “Is there personal data?” and then stores the answer in a spreadsheet. A useful PIA creates a record that connects statute, system, owner, risk, control, and evidence.

Build the assessment around these artifacts:

• Processing description: product, workflow, data categories, source systems, user groups, and specified purpose.
  ‍
• Data Principal rights map: how access, correction, erasure, grievance, and nomination rights under Sections 11 to 14 of the Digital Personal Data Protection Act, 2023 can be exercised for this workflow.
  ‍
• Notice and consent trail: what notice is shown, where consent or another lawful ground is captured, and how withdrawal propagates.
  ‍
• Risk assessment: what could go wrong for the Data Principal, not only what could go wrong for the company.
  ‍
• Control mapping: security, access, logging, retention, masking, encryption, vendor controls, and human review gates.
  ‍
• Processor register: every processor or vendor touching the data, the contract owner, the purpose, and the review date.
  ‍
• Residual risk decision: who accepted the remaining risk and why.
  ‍
• Evidence packet: screenshots, approval notes, data-flow diagram, test results, control owner, and timestamped sign-off.

The point is not the document. The point is whether the workflow produces evidence that can be reviewed later by leadership, auditors, customers, or the Data Protection Board.

‍

Who should own the PIA workflow?

Legal should not own the entire PIA alone. Security should not own it alone either. A PIA crosses systems and decisions.

A workable ownership model looks like this:

• Product owner: starts the assessment when a feature, journey, or data use changes.
  ‍
• Engineering or data owner: maps systems, storage, access paths, logs, APIs, and retention behavior.
  ‍
• Security: reviews safeguards, monitoring, breach detection, access control, and processor security controls.
  ‍
• Legal or DPO: interprets statutory obligations, rights impact, notices, consent, retention exceptions, and residual risk.
  ‍
• Procurement or vendor owner: updates processor records, contract clauses, review cadence, and offboarding evidence.
  ‍
• Leadership gate: accepts material residual risk for high-risk workflows.

This is where the manual process breaks. If the PIA lives as a legal questionnaire, product teams route around it. If it lives only as a security checklist, notice, consent, rights, and retention can be missed. The workflow has to show who did what, when, and why.

‍

How Redacto fits into the PIA workflow

Redacto’s role is not to replace legal judgment. Automation can prepare the decision, route approvals, maintain registers, and surface missing evidence. DPO, legal, security, and business owners still own interpretation, risk acceptance, and regulator-facing accountability.

Redacto’s DPDPA compliance platform lists Privacy Impact Assessment automation, AI-Driven Data Discovery & Mapping, Vendor Risk Management, Automated DSAR Management, Audit & Reporting, and related privacy governance capabilities.

In a PIA workflow, those capabilities matter because the assessment depends on inputs scattered across systems:

• data discovery helps identify what personal data the workflow actually touches;
  ‍
• PIA automation standardizes the risk questions and approval trail;
  ‍
• vendor risk management connects processor evidence to the assessment;
  ‍
• DSAR management checks whether rights workflows can operate against the same data map;
  ‍
• audit and reporting keep the evidence packet available when the annual SDF DPIA or audit is due.

Redacto is a stronger fit when the organization is India/DPDPA-first and needs one operating record across consent, PIA, ROPA, vendors, DSAR, and audit evidence. It is not the natural first pick for a global privacy team that mainly needs deep multi-jurisdiction GDPR, CCPA, and sector-specific workflow coverage out of the box.

Redacto also does not publish public pricing; evaluation is license-based and requires contacting Redacto.

Common PIA mistakes under DPDPA

The most expensive PIA failures are usually workflow failures, not drafting failures.

1. Treating PIA as a launch blocker instead of a design input. If the assessment starts after engineering is done, the only realistic outcome is paper approval.
   ‍
2. Copying GDPR DPIA templates without DPDPA mapping. GDPR templates can help with risk thinking, but DPDPA uses different statutory terms, rights, and fiduciary obligations.
   ‍
3. Ignoring vendors. A processor-heavy workflow is not assessed until the vendor register, contract owner, processing purpose, and offboarding path are visible.
   ‍
4. Leaving rights workflows out. Section 10’s DPIA definition points to Data Principal rights, so the assessment should test access, correction, erasure, grievance, and nomination pathways where relevant.
   ‍
5. Scoring risk without recording control evidence. A heatmap is not enough. The record should show the control, owner, implementation status, and residual-risk decision.
   ‍
6. Not refreshing the PIA after change. A model update, new data source, new vendor, retention change, or new geography can invalidate the original assessment.

‍

A practical PIA trigger checklist for this week

Start with one live workflow, not the whole enterprise. Pick a high-risk workflow such as digital KYC, patient onboarding, employee background verification, loan underwriting, loyalty analytics, or customer support recording.

Ask these questions:

• What personal data enters the workflow, and from which source?
  ‍
• What is the specified purpose for each data category?
  ‍
• Which systems, vendors, and teams receive the data?
  ‍
• What notice, consent, or other lawful basis supports the processing?
  ‍
• Can the Data Principal exercise access, correction, erasure, grievance, and nomination rights against this workflow?
  ‍
• What safeguards protect the data under Section 8(5) of the Digital Personal Data Protection Act, 2023?
  ‍
• What happens if consent is withdrawn or the purpose is complete?
  ‍
• Who approves residual risk, and where is that approval recorded?
  ‍
• If your organization becomes an SDF, can this PIA be reused in the annual DPIA and audit under Rule 13 of the Digital Personal Data Protection Rules, 2025?

Final answer: do not wait for the SDF letter to build the workflow

A PIA or DPIA is required under DPDPA when the organization is a Significant Data Fiduciary under Section 10 of the Digital Personal Data Protection Act, 2023, with Rule 13 of the Digital Personal Data Protection Rules, 2025 requiring an annual DPIA and audit from notification or class inclusion.

But the safer operating position is to run PIAs before high-risk processing changes, even before formal SDF designation. That gives the company a living evidence trail: what data was processed, why it was needed, which rights were affected, which controls were implemented, who accepted the residual risk, and what proof exists.

This week, pick one high-risk workflow and trace it from data collection to deletion. If you cannot identify the purpose, vendor, rights path, safeguard owner, retention rule, and approval record, do not wait for the formal DPIA deadline. Start the PIA there.

‍