The creator data sitting in your CRM is a ₹250 crore liability under the DPDP Act

Here is a question worth sitting with for a second. Somewhere in your agency right now there is a spreadsheet, a CRM, or a folder of onboarding PDFs that holds — for a few hundred to a few thousand creators — full name, PAN, bank account number, address, and the audience demographics you pitch to brands.

Under the Digital Personal Data Protection Act, that collection is no longer just an operational asset. As of 2026 it is a regulated liability, and the person legally on the hook for it is you, not your software vendor.

This post explains what the DPDP Act asks of an agency in plain terms, names the specific way most agencies are already non-compliant without knowing it, and lays out what “privacy by design” actually means before a regulator ever asks.

The two words that change your legal status: Data Fiduciary

The DPDP Act, 2023 — together with the DPDP Rules, 2025 — became fully operational across a phased timeline running into 2026. The Act uses two terms you need to internalise:

• Data Fiduciary — the entity that decides why and how personal data is processed. If you collect creator PAN to run payouts and creator audience data to pitch brands, you are the Data Fiduciary. This is you.
• Data Processor — a vendor that processes that data on your behalf under contract. Your analytics tool, your payout rail, your CRM host.

The trap is the assumption that liability follows the data. It does not. It follows the Fiduciary. Section 8(1) places non-delegable, vicarious liability on the Data Fiduciary for any processing done on its behalf — which means a breach at your vendor is, in the eyes of the law, your breach.

A “personal information” (PII) here is anything that identifies a living person: PAN, bank details, phone, address, and — critically for agencies — the audience-demographic profiles you build on each creator.

What the Act actually obligates you to do

Four obligations matter most for an agency holding a creator roster.

1. Consent that is real, in the SARAL format. Section 8 requires that consent be collected through a “standalone, clear, and simple” notice — the framework calls it SARAL (Simple, Accessible, Rational, Actionable). The consent has to be “free, specific, informed, unconditional, and unambiguous.” A buried clause in your onboarding contract that says “we may use your data” does not clear this bar. The notice must itemise what you collect and for what specific purpose.

2. A purpose limit on every field. You cannot collect a creator's PAN “for payouts” and then quietly feed it into a brand-pitch dataset. Each purpose needs its own consent.

3. Breach notification, promptly. Section 8(6) requires that on any personal-data breach you “promptly inform” both the Data Protection Board and every affected individual. There is no “it was the vendor's fault” exemption.

4. Deemed cessation — the delete button you don't have. This is the one almost nobody has built for. Under Section 8(8) and Rule 8, if a creator goes inactive and does not “approach” you for three years, you are required to erase their personal data. Not archive it. Erase it. For an agency whose database has only ever grown, this is a structural gap, not a policy gap.

The failure mode that costs ₹200 crore

Walk the concrete scenario. You store the historical audience demographics of, say, 10,000 creators to help brands target campaigns. A third-party analytics vendor — your Data Processor under a contract you signed — suffers a credential leak. Your IT lead discovers it and reasons: the vendor leaked it, so the vendor is liable.

Under Section 8(1), that reasoning is exactly backwards. The liability is yours, non-delegably. And by failing to notify the Board and the 10,000 affected creators promptly, you convert a containable incident into a penalty exposure of up to ₹200 crore under the Act's penalty schedule — the highest in the framework, which is why the brief ranks DPDP the single most severe compliance gap of 2026.

The quieter version of this failure is the deemed-cessation one: a database full of creators you last worked with in 2022, whose PAN and bank details you are still holding with no consent basis and no erasure mechanism. That is a standing liability that surfaces the moment a regulatory audit asks “show me your retention and erasure log.”

What privacy-by-design looks like before the regulator asks

The fix is architectural, and you can sequence it:

1. A consent ledger, not a consent checkbox. Record, per creator per purpose, when consent was given, what it covered, and when it was withdrawn. Consent withdrawal must be as easy as consent granting — that is a hard requirement, not a nicety.

2. Itemised notice templates. A dynamic generator that shows each creator exactly what you collect and why, in plain language. Reuse it at every new purpose.

3. Retention timestamps on every PII field. Every PAN, bank, and demographic record carries a “last active” date that feeds an automated deemed-cessation purge. This is the single highest-leverage change, because it converts an unbounded liability into a managed one.

4. Processor contracts with a breach SLA. Section 8(2) requires a “valid contract” with every Processor. Use it to push a fast breach-notification obligation onto the vendor — it does not transfer your liability, but it gives you the time to meet your own prompt-notification duty.

5. A breach playbook you have rehearsed. Who notifies the Board, who notifies creators, within what window. Decided in advance, not during the incident.

What SutraOS does about this

Data protection isn't something you bolt onto a creator roster after the fact — it's a property the platform has to have from the very first record. SutraOS exists to treat every creator's personal data as the regulated asset the DPDP Act says it is: collected for a clear purpose, kept secure, and set to expire when the law requires it. The whole point of running your roster on compliance infrastructure instead of spreadsheets is that the liability never quietly piles up in a corner of a database nobody owns.

And the rules will keep moving. Staying current with the DPDP regime as it evolves — and with whatever the Data Protection Board asks for next — is our burden to carry as the platform, not a fire drill that lands on your ops lead every time the framework changes. You run your roster; we keep it compliant by default.

---

If you run an agency holding a creator roster and the deemed-cessation gap above is one you have not closed, this is exactly the kind of structural risk SutraOS is built to absorb — and it's live today. Set up your workspace whenever you're ready, or for hands-on help we're taking 3–5 founding agencies as design partners. Twenty minutes, no deck.