Picture the meeting. A product head has just shown a feature the whole room likes: an AI model that scores customers from their transaction history. Heads nod. Then someone at the far end of the table asks, “Did anyone check what this does to those people’s rights?”
Nobody answers. Somebody else asks whether the law even makes us do that. Ten minutes later they’re still arguing.
So, does it? Depends who you are. But a data privacy impact assessment is worth doing either way, and here’s how to do one without a ready-made template.
Who actually has to do one
The duty lives in Section 10 of the Act, and Section 10 is only about Significant Data Fiduciaries, the companies the Central Government notifies as significant. Not everybody with a privacy policy. How does the government choose? By looking at the volume and sensitivity of the data, the risk to Data Principals’ rights, and bigger factors like sovereignty, electoral democracy, state security and public order.
If you do get notified, Rule 13 kicks in. You need a DPIA and an audit once in every twelve-month period, and whoever carries them out has to hand the Board a report of significant observations. Sit with that for a second. Your assessment can end up in front of the regulator.
Now the dates. These provisions start on 13 May 2027. As of early September 2026, nobody had been notified as an SDF yet. And because the twelve months run from notification, your first assessment is due a year after you’re designated, whenever that turns out to be. MeitY has talked about shortening the timeline, so it’s worth watching the gazette. Get it wrong and the ceiling is ₹150 crore.
Why a CEO should care
It looks like paperwork. It isn’t. A DPIA is where a company sits down, with evidence, and decides which risks to other people’s rights it’s prepared to live with. That’s a leadership decision, full stop.
There’s a commercial angle here too. Plenty of enterprise buyers now start asking for an impact assessment as part of the procurement process, & it’s not uncommon for investors to be asking about the AI risks involved. And if something goes wrong in a year from now, a report written 12 months ago that shows you had seen the risk coming & took action on it is going to carry a lot more weight than a policy that just says you care.
What the law says a data privacy impact assessment is
Section 10(2)(c)(i) describes it as a process covering a description of Data Principals’ rights and the purpose of processing, plus an assessment and management of the risk to those rights, along with anything extra the Rules prescribe. Read it slowly. Describe, assess, manage. Not “complete form 7B.”
Here’s the catch. The Rules say very little about how. The trouble is that the rules do not spell out who must serve as the outside auditor. They don’t actually say what should be included in your write up, or when it needs to be finalised. This gives you a fair amount of leeway in how you approach it, with the added bonus that you’ll have to stand behind your choices as well.
| The law says | You decide | |
|---|---|---|
| Who must do it | Notified SDFs only | Whether to run a lighter version anyway |
| How often | Every 12 months after notification | Redoing it when processing changes a lot |
| What it covers | Rights, purpose, risk | Your method, scoring and depth |
| What reaches the Board | A report of significant observations | Format and timing, which aren't prescribed |
Illustrative summary of Section 10 and Rule 13, not legal advice.
Three words get muddled here. A ROPA is the inventory of what you process. An audit checks whether you comply today. A DPIA looks ahead and asks what could go wrong for people if you carry on as you are. They all draw on the same facts, which is why getting the first one right makes the other two much cheaper.
Figure 1. A DPIA in seven steps, repeated every 12 months or when the processing changes materially.
Running a data privacy impact assessment in seven steps
Let’s walk it through using that AI scoring feature.
1. Pick one thing to review. Do not go broad. Choose a single piece, like the scoring model, the patient app, or the loyalty program. Start with what affects the most people. Or start with the part that uses the most sensitive data. If something is new tech, like AI, review that first.
2. Explain it in simple terms. What data goes in? Who sends it? What is the reason for it? Where does it go after that? Who works with it day to day? How long is it kept in systems before it is removed? For our model that’s transaction history in, a score out, a third-party model host in the middle, scores kept for three years. Got a ROPA and a data map? Mostly copy and paste. Haven’t? This is the step where you discover how much nobody knew.
3. Put the rights on the page. The Act asks for this by name. So for this processing: how does someone see their data, fix it, erase it, complain, pull their consent? Can they actually withdraw from a model? Could your team find their records in a vector store, or would that be a three-week project?
4. Ask whether you need all of it. Does the purpose really need three years of history, or would six months do? Honestly, this one question trims the risk list faster than any control you could buy.
5. Score the risks to people. Likelihood against severity. A wrongful credit decline. Exposure in a breach. Data quietly used for something else. A wrong record causing real harm. Data hanging around after consent is gone.
6. Give each risk a clear owner and a deadline. The truth is - if nobody’s name is associated with a particular risk, then technically it’s just a nagging worry, not a viable plan. Some of those fixes can be pretty straightforward & surprisingly quite effective - eg turn down the data being processed, tighten up security around who has access, get a human to go over & double-check any automated decision-making, set up some basic data retention policies & make sure your vendors are held to a high standard.
7. Sign it, file it, diarise the re-run. The business owner and DPO sign. For an SDF, the auditor’s report goes on to the Board. And it comes round again every year, or sooner if the processing changes in a big way.
Figure 2. Scoring the risks: likelihood against severity, with example risks plotted.
What the finished document looks like
Don’t get too hung up on the format - six basic sections should be enough: a clear, plain-language explanation of what data processing is happening, a list of the rights involved and a quick rundown on how each one is actually being respected, a risk register with some sort of scoring system, a mitigation plan with owners and deadlines, a sign-off page, and a note on when to review it all. The real test is simple: could a non-technical board member read through it in 10 minutes and tell you the top three risks they spotted? If so, then you’re on the right track.
One line from our scoring model’s register, to make it real. Risk: a customer is declined on stale data. Right at stake: correction. Rating: high. Fix: monthly refresh, plus a human look at declines. Owner: head of credit. Due: before launch.
Who should be in the room
The business owner, because the risk is theirs. The DPO, who runs the process. Security and engineering, who know what’s really going on under the bonnet. Legal. And for an SDF, the independent auditor.
Then the bit that often gets dodged. Someone senior has to accept whatever risk is left, in writing. A DPIA nobody senior signs is just a document. One a CEO or MD signs is a decision.
Not an SDF? Still worth it, probably
If you’re launching some new AI-powered features, or working with kids’ data, or delving into sensitive areas like health or financial records, or if enterprise customers keep asking for data protection assessments as part of the procurement process, then you’ll probably find one of these assessments useful anyway. Building this stuff right from the start is actually a pretty solid defence strategy.
One thing to watch out for: don’t go around calling yourself an SDF in customer paperwork unless you’ve actually been officially notified as one. Instead, just call it a voluntary data protection impact assessment and keep it nice and light: a few pages, one person in charge, and a review every 12 months or so.
And AI is the obvious trigger. The minute a model decides something about a person, or a vendor’s model starts ingesting your customer data, the rights questions get a lot sharper. An assessment is the cleanest way to show you asked first.
Where these go wrong
Mostly the same few ways. People treat it as a one-off, when Rule 13 is annual and the processing never sits still. They write it after launch, which makes it paperwork, because by then it can’t change anything. They list generic risks like “data breach” when what’s needed is “loan declined on stale data,” something tied to a person’s rights. They skip owners and dates. They wave through independence: the Rules don’t define it, so the judgement is yours to make, and to defend to the Board. They lean on a template as though it were thinking. And they forget the vendors, whose processing is still your risk.
What to do this quarter
Five things, in this order.
- List your five highest-risk processing activities.
- Pick one and run a dry-run DPIA.
- Settle on a template and a scoring method, and stick to it.
- Name the owners and get a senior signature on the residual risk.
- Keep an eye on the gazette for SDF notifications.
If you want a head start, Consiva’s Enterprise plan includes DPIA and audit management with DPDP-native templates, an SDF annual audit trail and a DPO workflow, and your ROPA and data discovery feed straight into step two. Take a look at the pricing page, or talk to the team.
Frequently Asked Questions
Only if the government has named you a Significant Data Fiduciary. Section 10 gives the government that power, and it looks at things like how much data you handle and how sensitive it is. If you haven’t been named, there’s no legal duty. Still, if you handle health, money or children’s data, running one anyway is a smart way to show you’ve taken care.
At least once every twelve months, counted from the date you were notified as an SDF. That’s what Rule 13 says, so your calendar starts on that date, not at the start of your financial year. Don’t wait a full year if something big changes, though. A new product, a major vendor or using AI on personal data are all good reasons to run it again.
Not the whole thing. Only a report of the key findings goes to the Board, and it’s sent by the person who did the assessment and audit. The full DPIA stays with you. Keep it complete and signed, since you may need to explain anything the report points out. It’s also smart to fix the big issues before the report is filed, not after.
It can get expensive. Failing to meet an SDF’s extra duties, which include the yearly DPIA, can lead to a penalty of up to ₹150 crore. The Board decides the final amount by looking at how serious the failure was, how long it went on and what you did to fix it. And without a DPIA, you have nothing on paper to show you took the risks seriously.
Section 10 lists the basics. You need to describe the rights of the people whose data you handle and why you’re processing it. Then you look at what could go wrong for them and how you’ll manage those risks. In simple terms, write down what data you collect, why, who can see it and where the danger is, and give every risk a fix and an owner.
They’re close cousins, but not twins. Under GDPR, any company has to do one before starting high-risk processing. Under the DPDP Act, only notified Significant Data Fiduciaries have to, and they must repeat it every year. If you already do GDPR DPIAs, you don’t need to start from scratch. Just check your template against DPDP’s own rules and terms.