Foundations and commencement · DP003
What counts as personal data in an ordinary Indian business?
Recognise personal data in invoices, staff records, support tickets and device information, and understand why removing a name may not make a record anonymous.
Research cutoff: . This dated explainer is general information; check the linked instruments and your circumstances before acting.

The most useful way to recognise personal data is to ask who can connect the information to a person. A name makes the connection obvious. A customer number, device identifier or delivery reference may make it possible through another system. Removing a name from a spreadsheet does not necessarily remove that connection.
The DPDP Act defines personal data as data about an individual identifiable by or in relation to that data. Its definitions have commenced; the main processing obligations are scheduled for the May 2027 phase as of 22 October 2026. Read the definition in section 2 with the phased commencement notification when preparing your inventory.
Look beyond the customer database
In an ordinary business, personal data can appear in invoice contact details, delivery instructions, job applications, employee attendance, call recordings, complaints and access logs. A support message may reveal considerably more than the fields in the customer-management system: an illness, a family relationship or a new home address.
Information about a company is not automatically personal data. Its registered office and aggregate annual sales may concern the legal entity. However, a named contact’s mobile number, a sole trader’s identifiable account information or a note about a particular employee can concern an individual. Business-to-business activity therefore still needs a person-level assessment.
Avoid judging only the column heading. A field labelled “comments” might contain delivery preferences in one record and an employee’s health information in another. The team that actually enters and reads the information often knows more about this variation than the person who designed the form.
Three examples from a hypothetical repair business
The obvious record: a service booking contains Anika’s name, mobile number and collection address. Staff can identify her immediately. The purpose, access and retention questions are straightforward to locate, even if the answers still need work.
The linked record: the workshop exports job numbers and fault descriptions without names. Another application maps each job number to a customer. The export has not necessarily become anonymous, particularly when the same people can access the mapping. Treat the removal of visible identifiers as a protective step, not an automatic change of legal status.
The aggregate record: a weekly report shows that the workshop completed 140 battery replacements across several locations. If no person is identifiable from the report or related context, the report may fall outside the personal-data definition. But a report saying one named employee handled a single identifiable customer’s unusual repair presents a different question.
The point is not to declare every number personal. It is to examine the real information environment, including who receives the file and what else they can connect to it.
Sensitivity changes handling even when the label does not
The DPDP Act does not establish a general sensitive-personal-data category equivalent to the separate 2011 SPDI Rules. Nevertheless, consequences matter. A lost delivery preference and a leaked medical note can expose people to different risks. Section 10 includes sensitivity among factors relevant to SDF designation, and section 33 includes the type and nature of affected data in penalty assessment.
An inventory can therefore include a practical sensitivity assessment without pretending that the business has created a new statutory category. Explain why a dataset deserves tighter access, reduced copying or additional verification. Check separate sector and existing legal requirements before deciding that a familiar category has no special rules.
A discovery exercise that staff can finish
Ask each function to name its three most-used records about people and its most common export. For each, record the person concerned, identifying link, business purpose, system and usual recipients. Then inspect a small authorised sample, preferably with unnecessary details concealed, to see whether free-text fields contain unexpected information.
Include overlooked locations: shared inbox attachments, spreadsheet downloads, printed reports, messaging groups and cloud folders. An inventory that describes only the central application will miss many of the copies that cause operational problems.
Do not collect an additional dataset of real customer information merely to prove that discovery occurred. Record categories, locations and observations where that is sufficient. A screenshot containing full records can create a new sensitive copy with no useful purpose.
Finish by assigning an owner to uncertain datasets. Document why the team considers information identifiable or anonymous and what assumptions that conclusion depends on. If a recipient gains access to a linking table later, revisit the conclusion. Identifiability is a question about the data and its context, not a permanent badge attached to a file name.
Review every identifying link
Text version of the diagram
- Check visible identity: Name or contact details identify directly.
- Check linking keys: Customer or job number connects to another record.
- Check context clues: A rare event or small group can reveal identity.
- Check aggregation: Check whether any person remains identifiable.
- Handling decision: Document assessment and safeguards.
- Check visible identity → Check linking keys
- Check linking keys → Check context clues
- Check context clues → Check aggregation
- Check aggregation → Handling decision
Sources and reading context
These references support the original 22 October 2026 research. Source links and the date above make the scope of this article explicit.
- Digital Personal Data Protection Act, 2023 · Sections 2(t), 10(1) and 33(2)
Definition and relevance of sensitivity
- Commencement notification for provisions of the DPDP Act · Paragraphs (a) and (c)
Definitions versus substantive commencement
- Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011 · Rule 3, Gazette text hosted by WIPO Lex
Separate sensitive personal data categories under the 2011 Rules