How Many Data Principals Do You Actually Have? (Your First Answer Is Probably Wrong)

Why this number has consequences

Ask most Indian businesses how many Data Principals they hold and you will get a number pulled from the customer table. It is almost always wrong, usually by a wide margin, and the error runs in both directions depending on how it was counted.

This is not a trivia question. The DPDP Act lets the Central Government notify a Data Fiduciary, or a whole class of them, as a Significant Data Fiduciary, and that assessment weighs factors including the volume and sensitivity of the personal data being processed. Once notified, Rule 13 obligations follow: a Data Protection Impact Assessment and an audit every twelve months, a report of significant observations to the Board, algorithmic due diligence, and localisation of any personal data the Central Government specifies.

Volume also shapes what Rule 6 asks of you, because reasonable security safeguards are judged against what you are actually protecting. If you do not know the size of the thing, you cannot argue your safeguards are proportionate to it. Our DPDP compliance checklist assumes you can answer this. This article is how you get there.

What the Act actually counts

A Data Principal is the individual to whom the personal data relates. That is the whole test. It says nothing about whether they paid you, signed up, or ever visited your website.

So your Data Principals include, at a minimum:

• •Customers, past and present, including ones who never completed a purchase
• •Your own employees, and everyone whose CV you kept after an interview
• •Contractors, consultants and the named contact person at every vendor
• •Newsletter subscribers and anyone who filled in a contact form
• •People who raised a support ticket or a complaint
• •Website visitors who interacted with your consent banner

Why counting customers undercounts

Take a modest Indian D2C brand that would describe itself as having twelve thousand customers. Counted properly:

The business would have told you twelve thousand. It holds more than three times that. Nothing here is exotic, and none of it is optional under the Act.

Why counting consent records overcounts

The opposite error is reading a number straight off a consent management dashboard. Most consent platforms, including ours, identify a visitor by a cookie written to their browser. That is a sensible engineering choice and a poor headcount.

• •One person on a phone and a laptop counts twice
• •Clearing cookies creates a new identity for the same person
• •Private browsing creates one every session
• •Anyone who never interacted with the banner is invisible

So a consent dashboard reporting forty thousand is describing browsers, not people. If a vendor labels that figure data principals without qualification, treat the label with suspicion, because the number can be inflated several times over before anyone has done anything wrong.

The fix is identity resolution. Where you hold a stable identifier for someone, such as a hashed email address, a phone number or an account id, collapse all of their browser sessions into one person. What remains unresolved is an anonymous browser, and it should be reported as one.

Where your Data Principals actually live

For a product company, most personal data sits in the production database and the answer is mostly a query. For everyone else it does not, and this is where counting quietly fails.

• •Spreadsheets on a shared drive, which is where most payroll, vendor and applicant data lives
• •Email inboxes, including the attachments nobody ever deleted
• •A CRM that predates whoever runs it now
• •HR files, often scanned and stored as images
• •WhatsApp groups and exported chat backups
• •Paper, still, in a very large number of Indian offices

A chartered accountancy practice is the clearest case. Its website might see four hundred visitors a month, so every web-derived metric reads close to zero, while the firm holds PAN numbers, bank statements and payroll records for the employees of every company it serves. On the web meter it looks like the smallest business you have ever seen. In reality it may hold more sensitive personal data than a funded startup.

This is why a discovery scan across file shares and drives finds what a consent dashboard never will, and why the output belongs in your RoPA rather than in a slide.

The honest method: three numbers, not one

There is no exact count, for anyone. Identity resolution without a universal key is an unsolved problem in general, and any vendor claiming a single precise figure is rounding somewhere they have not told you about. What you can do is be exact about what you know and honest about what you are estimating.

Report all three. A regulator, an auditor or an enterprise customer will respect a figure that states its own method far more than a single confident number that collapses under one question.

What to do once you have it

1. 1.Record each source and its rough volume in your RoPA, so the count is reproducible rather than remembered
2. 2.Check whether your security safeguards are proportionate to the real figure, not the one you assumed
3. 3.Look hard at the data you found and cannot justify keeping, because the cheapest way to shrink the number is to delete what you should not hold
4. 4.Re-run it when something structural changes, such as an acquisition, a new HR system or a migration

Most businesses find the exercise itself is the value. You cannot protect, map, or lawfully delete a category of people you did not know you were holding. If you are starting from nothing, work through how to implement DPDP compliance first, then come back and count.