If you’ve been asked by your CEO or board whether your company needs a Data Protection Officer under India’s Digital Personal Data Protection (DPDP) Act, the honest short answer is: probably not yet, legally — but you should start acting like you do.

That distinction matters more than most compliance checklists admit. Let’s walk through who’s actually on the hook, what a DPO is supposed to do under Indian law, and how to build the function before a regulator forces the timeline on you.

Who Legally Must Appoint a DPO Under the DPDP Act?

Here’s the part that surprises most founders and compliance leads: the DPDP Act does not require every company to appoint a Data Protection Officer.

Section 10 of the Act reserves that statutory duty for one category of organisation only — a Significant Data Fiduciary (SDF). And you don’t get to decide you’re an SDF; only the Central Government can formally notify you as one, based on factors like:

• The volume and sensitivity of personal data you process
• Whether you handle children’s data
• Your use of AI, profiling, or automated decision-making
• The risk your processing poses to individuals’ rights
• Whether your operations are systemically significant (think large platforms, critical infrastructure, widely used services)

As of now, this obligation sits in the 18-month commencement tranche of the DPDP Rules, putting the practical start date around May 2027. If you haven’t been notified as an SDF, you are not currently under a statutory duty to appoint a DPO — full stop.

So does that mean you can ignore this until 2027? Not really — and here’s why.

Why “We’re Not Legally Required Yet” Is the Wrong Question

Waiting for a government notification before you start building privacy governance is a bit like waiting for a fire before installing smoke detectors. A few reasons the SDF trigger shouldn’t be your only planning input:

You may already be closer to SDF territory than you think. If you’re scaling fast, processing financial or health data, running AI-driven credit or hiring decisions, or sitting on a large user base, you’re a strong candidate for future designation — and there’s no advance warning period once the government notifies your sector or company.

Enterprise clients and investors are already asking. Even without a legal mandate, large customers, banks, and due-diligence teams increasingly want to see a named privacy owner before they’ll sign a contract or close a funding round. A missing DPO-style function can quietly cost you deals that have nothing to do with the regulator.

Every company — SDF or not — still owes baseline DPDP duties. Consent, notice, breach handling, and grievance redressal obligations apply regardless of DPO status. Someone has to own that work whether or not their title says “DPO.”

The practical move most mature companies make: appoint a privacy lead or DPO-equivalent role voluntarily now, and formalise it into the statutory DPO position the moment an SDF notification arrives — rather than scrambling to build the function from zero under regulatory pressure.

What Does a DPO Actually Do Under DPDP? (It’s Not an IT Job)

One of the most common misreadings of this role: treating the DPO as an extension of IT security or a legal paperwork function. Under the DPDP framework, the DPO is closer to an internal risk control owner — someone with the standing to challenge business decisions, not just document them.

Core responsibilities that should sit with the DPO:

• Advising leadership on how DPDP requirements apply to new products, campaigns, and data uses — before launch, not after a complaint
• Owning the risk assessment process, including deciding when a Data Protection Impact Assessment (DPIA) is triggered for high-risk processing like AI scoring or large-scale profiling
• Acting as the primary point of contact for the Data Protection Board of India if a complaint or inquiry arises
• Overseeing grievance redressal — making sure data principal requests (access, correction, withdrawal) actually get resolved, not just logged
• Coordinating breach response in partnership with the security team, so notification timelines under the DPDP Rules are met
• Running (or commissioning) periodic audits of whether privacy controls work in practice, not just on paper

Equally important is what the DPO is not meant to do. This role should not:

• Personally run day-to-day IT security operations (that’s the CISO’s job — the DPO sets requirements and reviews outcomes)
• Rubber-stamp every product decision (that creates bottlenecks and dilutes the role’s authority)
• Carry revenue or P&L targets tied to the very products they’re supposed to independently scrutinise
• Be the sole person defending the company in litigation (Legal owns that; the DPO supports with facts and records)

Getting this boundary wrong is one of the fastest ways companies undermine their own DPO function — either by burying the role inside IT, or by handing it to someone with a conflict of interest.

Where Should the DPO Sit? Reporting Lines That Actually Work

The single most common design mistake: making the DPO report to the very function they’re meant to provide oversight over. If your DPO reports into product or marketing leadership, don’t be surprised when hard calls get softened.

Reporting structures that hold up better under scrutiny:

• DPO reports to the CEO, General Counsel, or Chief Risk Officer, with a standing right to escalate directly to the board or a risk committee
• A cross-functional privacy steering committee — DPO, CISO, Legal, HR, and key business heads — meeting at least quarterly
• Clear separation from the CISO (who runs security operations) and from Legal (who runs litigation strategy), even though all three work closely together

Think of it the way you’d think about internal audit: independent enough to say uncomfortable things, but embedded enough to actually influence decisions before they become problems.

Building DPO Readiness Before You’re Forced To

Rather than waiting for a mandate, here’s a practical sequence companies are using to get ahead of DPO obligations:

Step 1 — Map what you actually process. Build a working inventory of personal data: what you collect, why, where it lives, and who it’s shared with. This becomes the backbone of everything else — consent audits, DPIAs, vendor reviews, breach response.

Step 2 — Name an owner, even informally. Someone in your organisation needs explicit, board-acknowledged accountability for privacy — even if their title isn’t “DPO” yet. Ambiguous ownership is the most common reason privacy programmes stall.

Step 3 — Standardise your consent and notice flows. If every product team designs its own consent screen, you’ll never be able to answer a regulator’s question consistently. Fewer, reusable patterns beat bespoke screens every time.

Step 4 — Get your vendor contracts in order. Most privacy failures trace back to a third party, not the company itself. Make sure processors and partners are contractually bound to DPDP-aligned standards for consent, breach notification, and data handling.

Step 5 — Build (and rehearse) a breach response plan. Don’t wait for an actual incident to discover that nobody knows who’s responsible for notifying the Board within the prescribed timeline.

Step 6 — Report to the board on a fixed cadence. Even a lightweight quarterly update — open risks, incidents, request volumes, remediation status — builds the muscle memory a real DPO function needs.

DPO vs. CISO vs. Legal: Who Owns What?

A quick reference for a question that comes up in almost every governance discussion:

Frequently Asked Questions About Appointing a DPO in India

Do all companies need a DPO under the DPDP Act? No. Only organisations formally notified as Significant Data Fiduciaries are legally required to appoint one, with that obligation expected to commence around May 2027. Other companies can appoint a privacy lead voluntarily.

Can one person hold the DPO role alongside another job? Yes, particularly in smaller organisations — but conflicts of interest need careful management. Avoid combining the DPO role with a position that’s directly accountable for the revenue or performance of the products the DPO is meant to scrutinise.

Can we just outsource the DPO function to a consultant? External advisors can help design your programme, run assessments, and provide ongoing support — but legal accountability under the DPDP Act stays with your organisation and its designated DPO. Outsourcing execution is fine; outsourcing accountability isn’t possible.

What happens if we wait until we’re notified as an SDF to start? You’ll likely be building the entire function — data inventory, consent standardisation, vendor contracts, breach playbooks — under a compressed timeline, often while also responding to whatever triggered increased regulatory attention in the first place. Most organisations find it far less disruptive to build gradually.

How is the DPO role different from a Consent Manager? A Consent Manager is a separate, registered entity under the DPDP framework that helps individuals manage consent across multiple data fiduciaries. A DPO is an internal role within your own organisation responsible for privacy governance and regulatory liaison. The two serve different functions entirely.