Section 2 - Definitions

1.1 “In this Act, unless the context otherwise requires”

Section 2 begins with the words “In this Act”. This means that the definitions in Section 2 govern the use of these expressions throughout the DPDPA. They are statutory definitions, not merely explanations or examples.

The next words,“unless the context otherwise requires,” prevent the definitions from being applied mechanically where the context of a particular provision clearly requires a different reading. This is a limited interpretive safety valve. It does not permit an organisation to replace the statutory definition with its preferred contractual definition.

Example

For example, a contract cannot make a marketing agency a “Data Processor” merely by naming it one if the agency actually decides to use customer data for its own audience-building service. Similarly, an employee does not become a separate “Data Fiduciary” merely because an internal policy uses that label. The legal role depends on the Act’s definition as applied to the actual processing activity.

The definitions must therefore be applied:

1. to the actual facts;

2. to a specific processing operation or connected set of operations;

3. separately for each entity involved;

4. separately for each purpose; and

Commencement position: Section 2 came into force on publication of the Central Government’s commencement notification dated 13 November 2025. Most substantive provisions of the Act, however, including Sections 3 to 5, most of Section 6, and Sections 7 to 17, are scheduled to commence eighteen months after that publication. Section 2 is therefore already operative as a definition provision, although many provisions to which its definitions relate have not yet commenced as of 17 August 2026.

2. Section 2(a): “Appellate Tribunal”

The Appellate Tribunal is the Telecom Disputes Settlement and Appellate Tribunal, commonly called TDSAT, established under Section 14 of the Telecom Regulatory Authority of India Act, 1997.

The DPDPA does not create a separate privacy appellate tribunal. Instead, it assigns the appellate function to an existing specialised tribunal.

Under the DPDPA’s structure:

• the Data Protection Board of India makes decisions and issues orders within its statutory jurisdiction;

• an aggrieved person may appeal to the Appellate Tribunal under Section 29;

• the Appellate Tribunal may confirm, modify or set aside the order under challenge, according to the applicable statutory framework; and

• its orders are executable in the manner contemplated by Section 30.

The definition is institutional. It does not mean that every dispute involving personal data goes to TDSAT. The appellate jurisdiction arises only where the DPDPA provides an appeal from a Board order.

Practical illustration

A Data Fiduciary receives an adverse Board order imposing a monetary penalty. If it wishes to challenge that order, the designated appellate forum is TDSAT rather than a civil court or a newly constituted privacy tribunal.

2.1 GDPR comparison

The GDPR does not designate one EU-wide appellate tribunal. National supervisory authorities enforce the GDPR, and judicial remedies are pursued before competent national courts, with questions of EU law potentially reaching the Court of Justice of the European Union. The DPDPA creates a more centralised Indian appellate route through TDSAT.

3. Section 2(b): “Automated”

An automated process is a digital process capable of operating automatically in response to instructions given, or otherwise, for processing data.

The definition contains four elements:

1. there must be a process;

2. it must be digital;

3. it must be capable of operating automatically; and

4. its operation must be for processing data.

The word “capable” is important. The process need not operate without human involvement on every occasion. A system may be automated even if a human starts it, selects parameters or reviews the output.

Example

Examples include:

• an algorithm screening job applications;

• software calculating credit eligibility;

• a fraud-detection engine;

• an attendance system recording biometric entries;

• an email-marketing tool selecting recipients;

• a recommendation engine;

• payroll software computing salaries;

• an automated deletion routine;

• software identifying faces in CCTV footage; and

• a rule-based application that blocks suspicious transactions.

3.1 Automation versus ordinary digital processing

Not every digital operation is meaningfully automated.

An HR manager manually reading a PDF résumé on a laptop performs digital processing, but the reading itself is not an automated process. If software extracts qualifications and ranks candidates, that component is automated.

The distinction matters because the definition of “processing” refers to a wholly or partly automated operation performed on digital personal data. A process can therefore remain covered where only part of the workflow is automated.

3.2 Illustration 1: Automated payroll

The employer instructs payroll software to calculate monthly salary using attendance, leave, deductions and tax rules. The software runs automatically after configuration. The process is automated even though HR approves the final payroll.

3.3 Illustration 2: Human-supported recruitment screening

Software filters 10,000 applications based on experience and education. Recruiters manually interview the shortlisted candidates.

The filtering is automated processing. The interviews and human judgment do not remove the automated character of the earlier stage.

3.4 GDPR comparison

The GDPR does not define “automated” as a separate general term in precisely this manner. It regulates wholly or partly automated processing through Article 2 and gives special treatment to certain solely automated decisions under Article 22. The DPDPA defines “automated” broadly but does not contain a direct equivalent of the GDPR’s general Article 22 right concerning decisions based solely on automated processing that produce legal or similarly significant effects.

4. Section 2(c): “Board”

The Board is the Data Protection Board of India established by the Central Government under Section 18.

The Board is the DPDPA’s adjudicatory and enforcement body. Its functions include handling matters assigned by the Act, conducting proceedings, accepting voluntary undertakings where permitted and imposing monetary penalties after following the statutory process.

The Board should not be confused with:

• a Data Protection Officer; or

• TDSAT.

The final DPDP Rules, 2025 contain provisions governing the Board’s functioning and digital operations. Rules 17 to 21 commenced on publication of the final Rules.

4.1 GDPR comparison

The GDPR is enforced through independent supervisory authorities in EU Member States and coordinated through mechanisms involving the EDPB. The Indian Board is a central statutory body. The European Data Protection Board is not equivalent to the Data Protection Board of India: the former primarily coordinates European supervisory authorities, while the Indian Board directly performs adjudicatory and enforcement functions assigned by the DPDPA.

5. Section 2(d): “Certain legitimate uses”

“Certain legitimate uses” means the uses listed in Section 7.

This is a cross-reference, not an independent legal test. An organisation cannot invent a “legitimate use” by showing that its commercial interest is reasonable.

Section 7 contains a closed statutory list. It is materially different from the GDPR’s broad “legitimate interests” ground under Article 6(1)(f).

Under the DPDPA:

• processing must ordinarily rest on consent or a use specifically recognised under Section 7;

• “certain legitimate uses” do not create an open-ended balancing test;

• commercial convenience is not itself a Section 7 ground; and

• a Data Fiduciary must identify the precise clause of Section 7 on which it relies.

Illustration

An e-commerce company wishes to profile customers for unrelated advertising because profiling is profitable. It cannot merely say that advertising is a legitimate business interest. It must establish consent or identify a particular Section 7 use.

5.1 GDPR comparison

Under Article 6(1)(f) GDPR, a controller may sometimes process data where necessary for its legitimate interests or those of a third party, unless overridden by the individual’s interests or fundamental rights. That requires a purpose, necessity and balancing assessment. The DPDPA has no general equivalent. The similar language must not conceal the structural difference.

6. Section 2(e): “Chairperson”

The Chairperson is the Chairperson of the Data Protection Board of India.

The definition identifies a statutory office. The Chairperson performs functions assigned under the Act and relevant Rules, including responsibilities connected with the Board’s administration and proceedings.

The Chairperson is also included within the definition of “Member” under Section 2(q). Therefore:

• every Chairperson is a Member;

• not every Member is the Chairperson.

6.1 GDPR comparison

The GDPR does not create an equivalent single EU enforcement chairperson. National supervisory authorities have their own governance arrangements, while the EDPB elects a chair for its coordination functions.

7. Section 2(f): “Child”

A child is an individual who hasnot completed eighteen years of age.

A person remains a child until completing the age of eighteen. The definition applies uniformly across the DPDPA unless a statutory notification or other provision validly alters the operational consequence in a particular context.

The definition is important because Section 9 imposes special conditions on the processing of children’s personal data, including verifiable parental consent and restrictions concerning detrimental effects, tracking, behavioural monitoring and targeted advertising, subject to statutory exemptions and the final Rules.

7.1 Difficult issues

8. Age-established versus age-unknown users

An organisation cannot assume that every user who clicks “I am over 18” is an adult where the service, context or known facts indicate otherwise. At the same time, the Act does not necessarily compel intensive identity collection from every low-risk service merely to prove age. The applicable verification method must be read with the final Rules.

9. Indian child using a foreign service

If a foreign service offers goods or services to a Data Principal within India, overseas processing may fall within Section 3(b). The definition of child then affects the processing even if the provider’s home law has a lower age threshold.

10. Eighteenth birthday

After the individual completes eighteen years, she ceases to be a child for future processing. The organisation should consider whether permissions previously exercised through a parent or lawful guardian need to transition to the individual.

10.1 Illustration 1: Gaming application

A sixteen-year-old creates an account on an Indian gaming application. The application cannot treat the user as an adult merely because its global terms define children as persons under thirteen.

10.2 Illustration 2: School alumnus database

A school continues contacting an alumnus after she turns eighteen. The school should update the relationship and its consent or communication process rather than indefinitely treating the parent as the relevant decision-maker.

10.3 Illustration 3: Family device

A parent creates a streaming account that is used by a child. Whether a particular profile involves processing of the child’s data depends on whose viewing behaviour, preferences and identity the platform processes. The parent’s ownership of the subscription does not automatically convert the child’s data into the parent’s data.

10.4 GDPR comparison

The GDPR defines a child less directly and allows Member States to set the age for a child’s own consent to information-society services between thirteen and sixteen. The DPDPA adopts eighteen as the general threshold, making its child-related regime potentially broader.

11. Section 2(g): “Consent Manager”

A Consent Manager is:

1. a person;

2. registered with the Board;

3. acting as a single point of contact;

4. enabling a Data Principal to give, manage, review and withdraw consent;

5. through an accessible, transparent and interoperable platform.

A Consent Manager is not merely any consent-management software vendor. Registration with the Board is an express element of the definition.

11.1 “Single point of contact”

The Consent Manager provides a unified interface through which the Data Principal can deal with consent across participating Data Fiduciaries or processing contexts.

11.2 “Give, manage, review and withdraw”

The function continues throughout the consent lifecycle:

• give: communicate valid consent;

• manage: handle active permissions;

• review: see what permissions exist;

• withdraw: revoke consent through the platform.

11.3 “Accessible”

The platform should be usable by the intended Data Principals, including through appropriate language, interface and accessibility design.

11.4 “Transparent”

The platform should make it clear:

• which Data Fiduciary seeks consent;

• for what purpose;

• for which personal data;

• what has already been allowed; and

• how withdrawal works.

11.5 “Interoperable”

The platform should be capable of operating across systems rather than locking the Data Principal into a closed, proprietary arrangement.

A Consent Manager does not necessarily become a joint Data Fiduciary merely because its infrastructure facilitates consent. Its role depends on whether it determines purposes and means for any processing of personal data. It will ordinarily be a Data Fiduciary for personal data it processes for its own account, such as account administration, fraud prevention or statutory compliance. It may act in another capacity for consent-transmission activities, depending on the actual arrangement.

11.6 GDPR comparison

The GDPR recognises consent-management technologies but does not establish an equivalent general category of a regulator-registered “Consent Manager” serving as an interoperable single point of contact.

12. Section 2(h): “Data”

“Data” means a representation of:

• information;

• facts;

• concepts;

• opinions; or

• instructions, in a manner suitable for:

• communication;

• interpretation; or

• processing by human beings or automated means.

The definition is extremely broad. It is not limited to truth, objective fact or numerical records.

12.1 Opinions are data

Example

Examples include:

• an interviewer’s assessment;

• a performance rating;

• a doctor’s provisional diagnosis;

• a manager’s view that an employee is unreliable;

• a credit analyst’s opinion; and

• a customer’s review.

An opinion may be inaccurate, unfair or disputed, but it is still data.

12.2 Instructions are data

Example

Examples include:

• computer code;

• automated rules;

• commands;

• workflow instructions; and

• configuration parameters.

Whether such data is personal data depends on whether it is about an identifiable individual.

12.3 Inferred information is data

A probability or inference can be data even if not directly supplied by the individual. Examples include:

• “likely to resign”;

• “high credit risk”;

• “interested in pregnancy products”;

• “possible political preference”; and

• “likely premium customer.”

12.4 Incorrect information remains data

If a database wrongly records that Ravi has defaulted on a loan, the entry is still data about Ravi. Its falsity creates an accuracy issue rather than removing it from the definition.

12.5 GDPR comparison

The GDPR does not separately define “data” in this general way. It defines “personal data” as information relating to an identified or identifiable natural person. The DPDPA builds its concept in stages: data, personal data and digital personal data.

12.6 Data Fiduciary, Data Processor and independent professional

The central question is not whether an entity is called a “service provider.” The question is whether personal-data processing is carried out:

• for the customer’s purpose and on its behalf; or

• for a purpose determined independently by the service provider.

12.7 Consulting service providers

The word “consultant” does not determine the role.

12.8 Scenario A: Processor consultant

A compensation consultant receives employee data and calculates salary benchmarks using:

• the client’s prescribed methodology;

• the client’s employee categories;

• the client’s reporting format; and

• no independent reuse.

The consultant is likely a Data Processor for that activity.

12.9 Scenario B: Independent Data Fiduciary consultant

A consulting firm collects information through interviews, selects what evidence to rely on, applies its professional methodology, retains working papers according to its professional requirements and issues an independent assessment.

The firm may be a Data Fiduciary for that processing because it determines substantial purposes or means as part of its professional function.

12.10 Scenario C: Mixed role

A consultant first hosts an employee survey strictly under the client’s instructions, then combines de-identified or identifiable material with its own benchmark database.

It may be:

• a Data Processor for administering the client survey; and

• a separate Data Fiduciary for any independent benchmarking involving personal data.

The same agreement can therefore contain more than one role.

12.11 Law firms

A law firm is not automatically a Data Processor merely because it is retained by a client.

A law firm may independently decide:

• which documents are legally relevant;

• which witnesses to interview;

• what material to disclose;

• what evidence to retain;

• what litigation strategy to follow;

• what professional records must be maintained; and

• what information is required for conflict checks or legal compliance.

Where the firm exercises such professional independence, the stronger classification is ordinarily that the firm is a separate Data Fiduciary for those legal-service operations.

The EDPB similarly treats a law firm independently deciding what case information to use and how to use it as a controller under the GDPR..pdf)

12.12 But a law firm can act as a processor for a limited operation

Suppose a law firm is instructed only to:

• host a document-review platform;

• apply client-prescribed search terms;

• tag documents using client instructions; and

• return the results without independent legal assessment.

For that narrowly defined operation, it may act as a Data Processor.

12.13 Case study: Litigation and e-discovery

Company A engages Law Firm B in a dispute. Firm B appoints e-discovery Provider C.

• Company A is a Data Fiduciary for collecting and preserving employee mailboxes for the dispute.

• Firm B may be an independent Data Fiduciary for professional legal analysis and legal-record obligations.

• Provider C may be a Data Processor for hosting and searching documents on the instructions of Firm B, Company A or both, depending on the arrangement.

• If Provider C uses the documents to train its own litigation-prediction product, it becomes a Data Fiduciary for that independent processing.

12.14 Marketing agencies

Marketing agencies frequently present mixed roles.

12.15 Processor model

The client determines:

• campaign purpose;

• customer list;

• audience;

• communication;

• timing;

• channel;

• suppression rules; and

• retention.

The agency merely sends communications and reports results. It is likely a Data Processor.

12.16 Independent Data Fiduciary model

The agency:

• maintains its own consumer database;

• selects individuals using its proprietary profiles;

• combines information across clients;

• determines targeting methodology;

• retains campaign data for its own analytics; or

• sells audience access.

It is likely a separate Data Fiduciary for those activities.

12.17 Joint Data Fiduciary model

The client and agency jointly decide:

• the audience;

• the data sources;

• the customer segments;

• the matching methodology;

• the communication strategy;

• follow-up profiling; and

• shared campaign outputs.

They may be Data Fiduciaries “in conjunction” for the jointly determined processing.

12.18 Case study: Marketing agency exceeds instructions

GoodProducts supplies a customer list to MarketinZ solely to send a specified product campaign. MarketinZ adds those customers to its own advertising graph and offers them to other clients.

MarketinZ is a Data Processor for the instructed campaign, but a Data Fiduciary for its unauthorised audience-building. The uploaded EDPB guidance uses an equivalent service-provider example to show that introducing an independent purpose converts the provider into a controller for that additional processing..pdf)

12.19 Data Fiduciaries acting “in conjunction”: joint Data Fiduciaries

The Act does not separately define “joint Data Fiduciary.” The legal basis for the concept is contained within Section 2(i): a person may determine purposes and means “alone or in conjunction with other persons.”

Two or more persons are joint Data Fiduciaries where they jointly determine the purpose and means of the same processing operation or connected set of operations.

The following are not enough by themselves:

• signing a commercial contract;

• receiving economic benefit;

• sharing data;

• using a common vendor;

• operating within the same corporate group;

• participating in the same project;

• using the same database; or

• processing the same individual’s data.

The core question remains:

Did the parties determine the relevant purpose and means together?

12.20 Common decisions

Joint determination can arise through an express common decision.

Example

Example:

Two companies launch a co-branded product and jointly decide:

• which customers will be invited;

• which customer databases will be matched;

• which fields will be used;

• which communication channels will be used;

• how responses will be analysed; and

• how follow-up marketing will occur.

They are likely joint Data Fiduciaries for that campaign.

12.21 Converging decisions

The DPDPA does not expressly use the EDPB’s phrase “converging decisions.” However, it can assist in understanding when parties determine processing “in conjunction.”

Under that approach, separate decisions may amount to joint participation where they:

• complement each other;

• are necessary for the processing;

• materially influence the purpose and means; and

• make the parties’ participation inseparable for the relevant operation.

The EDPB emphasises that ordinary commercial cooperation or mutual benefit is not enough..pdf)

12.22 Joint responsibility need not be equal

One party may design the platform while another chooses the audience. One may interact with Data Principals while another performs matching. Their influence may differ.

Joint status should therefore be confined to the processing operations jointly determined. Each party may remain a sole Data Fiduciary for other operations.

12.23 No equivalent of GDPR Article 26

The GDPR expressly requires joint controllers to establish an arrangement allocating responsibilities, make its essence available to data subjects and permit rights to be exercised against each joint controller.

The DPDPA contains no exact equivalent of Article 26. That difference is important. Indian organisations should not claim that Article 26’s detailed legal consequences automatically apply.

Nevertheless, a written joint-fiduciary arrangement is operationally necessary. It should allocate:

• notice delivery;

• consent collection;

• withdrawal;

• grievance handling;

• access requests;

• correction and erasure;

• security;

• processor appointment;

• breach investigation;

• notification to affected Data Principals;

• reporting to the Board;

• retention;

• deletion;

• audit;

• indemnity; and

• regulatory cooperation.

A contract allocates tasks between the parties but cannot change their factual statutory roles or bind the Board’s legal assessment.

12.24 Fifteen role-classification case studies

12.25 Case study 1: Standard cloud storage

Company X chooses a cloud provider to store customer files. Company X determines why the files are stored, whose data is included, authorised users and retention. The provider offers standard infrastructure and uses the files only to provide storage.

12.26 DPDPA classification:

• Company X: Data Fiduciary.

• Cloud provider: Data Processor.

• The provider’s standard terms do not make it a Data Fiduciary if it has no independent purpose.

The corresponding EDPB illustration reaches the same functional result under the GDPR..pdf)

12.27 Case study 2: Payroll administrator and bank

Employer A instructs Payroll Company P to calculate salaries and transmit payment instructions. Bank B executes the payments under banking rules and determines its own retention, fraud controls and account processes.

12.28 Classification:

• Employer A: Data Fiduciary for employee payroll.

• Payroll Company P: Data Processor for payroll administration.

• Bank B: separate Data Fiduciary for banking operations.

The bank does not act merely on the employer’s behalf in relation to its regulated banking functions. The EDPB’s payroll-bank example draws this same distinction..pdf)

12.29 Case study 3: Statutory auditor

Company A gives financial records containing employee and customer details to an independent auditor. The auditor determines what evidence is needed, testing methodology, working-paper retention and disclosures required by law.

Classification: The auditor is ordinarily a separate Data Fiduciary for the audit processing.

If an accounting vendor merely enters figures into software under detailed instructions, it may instead be a Data Processor. The professional title does not settle the role.

12.30 Case study 4: Customer-support call centre

A retailer supplies customer details and scripts to a call centre. The call centre may use data only to answer the retailer’s customers and may not reuse it.

12.31 Classification:

• Retailer: Data Fiduciary.

• Call centre: Data Processor.

The call centre may select software and staffing methods without becoming a Data Fiduciary if those are implementation choices serving the retailer’s purpose..pdf)

12.32 Case study 5: General IT support

An IT provider has systematic administrator access to a company’s systems and inevitably handles employee and customer data while maintaining them.

Classification: The provider is likely a Data Processor even though personal-data processing is incidental to the commercial description of “IT support.”

The contract should cover the actual access rather than assuming that only a “data service” can involve a processor. The uploaded practice note similarly distinguishes systematic IT access from contracts that do not involve personal data..pdf)

12.33 Case study 6: One-time bug repair

An external specialist repairs software under supervision. Access to live personal data is neither required nor authorised, and the company uses test data and access restrictions.

Classification: The specialist need not be a Data Processor merely because accidental exposure is theoretically possible.

If the specialist is given systematic production access, the conclusion changes. The EDPB draws this distinction between general IT support and limited bug repair..pdf)

12.34 Case study 7: Travel agency, airline and hotel

A travel agency sends customer data to an airline and hotel to book travel. Each entity provides its own service, determines operational data requirements and retains records for its own obligations.

Classification: The travel agency, airline and hotel are ordinarily separate Data Fiduciaries, not joint Data Fiduciaries and not parties to a fiduciary-processor chain.

If they jointly build a platform, agree on customer data, booking allocation, access and common marketing, they may become joint Data Fiduciaries for that platform and marketing while remaining separate Data Fiduciaries for their independent activities..pdf)

12.35 Case study 8: Taxi platform for corporate travel

Company ABC books an airport taxi for an employee. The taxi platform independently determines booking fields, driver allocation, safety records, billing and retention as part of its transportation service.

Classification: The taxi platform is ordinarily a separate Data Fiduciary, not ABC’s Data Processor.

Processing follows ABC’s request, but the platform does not merely process data on ABC’s behalf. The EDPB’s taxi example illustrates this distinction..pdf)

12.36 Case study 9: Recruitment agency using its own candidate database

Employer Y supplies CVs to Agency X. Agency X combines them with its independently built candidate database and proprietary matching service. Both parties’ decisions are necessary for the combined matching process.

12.37 Classification:

• X and Y may be joint Data Fiduciaries for the combined matching operation.

• X is a sole Data Fiduciary for maintaining its independent candidate database.

• Y is a sole Data Fiduciary for interviews, offers and employment.

The EDPB’s headhunter illustration supports this operation-specific separation..pdf)

12.38 Case study 10: Co-branded marketing event

Companies A and B launch a joint product. They combine prospect lists and jointly choose invitees, invitations, feedback questions and follow-up marketing.

Classification: A and B are joint Data Fiduciaries for the event-related processing because they determine both purpose and essential means together.

They remain separate Data Fiduciaries for unrelated customer processing..pdf)

12.39 Case study 11: Clinical research project

A hospital and university jointly draft the study protocol, choose participants, determine data fields, agree methodology and decide research reuse.

Classification: They are likely joint Data Fiduciaries for the research processing.

The hospital remains a separate Data Fiduciary for patient care. If it simply follows a complete protocol without influencing the study purpose or essential means, it may act as a Data Processor for the research component, depending on Indian legal and professional constraints.

The EDPB’s clinical-trial illustration makes the same operation-specific distinction under the GDPR..pdf)

12.40 Case study 12: Shared group HR database

Several group companies use common infrastructure. Each company controls its employees’ records, access, retention and use. The parent only hosts the system without independent use.

12.41 Classification:

• each employer: separate Data Fiduciary;

• parent-host: Data Processor for hosting;

• no joint fiduciary status arises merely from shared infrastructure.

If the parent later collects all employee data for its own workforce analytics, it becomes a Data Fiduciary for that additional processing..pdf)

12.42 Case study 13: Law-enforcement disclosure

An employer processes salary information for payroll and discloses specified data to a tax authority under law. The authority uses it for fiscal enforcement.

Classification: The employer and authority are separate Data Fiduciaries. They process the same data for different purposes and do not jointly determine the relevant processing. The EDPB uses an equivalent tax-authority example..pdf)

12.43 Case study 14: Cleaning company

A cleaning company enters an office but is neither instructed nor permitted to access personal data. Documents are locked and screen access is restricted.

Classification: The cleaning company is not a Data Processor merely because its employees could accidentally see information. Security and confidentiality controls remain necessary.

If cleaners are expressly instructed to sort personnel files or destroy identified records, they may process personal data on behalf of the company for that activity..pdf)

12.44 Case study 15: Health-analytics collaboration

A hospital, health application provider and analytics company jointly decide to study whether blood-pressure changes predict disease. They agree on data, methodology, features and outputs.

Classification: They are likely joint Data Fiduciaries for the defined research project.

If the analytics company merely runs a model specified by the hospital and app provider, without a purpose of its own, it may be their Data Processor. The EDPB’s health-data illustration draws this distinction..pdf)

12.45 Practical role-classification test

For each operation, ask:

13. Section 2(j): “Data Principal”

A Data Principal is the individual to whom the personal data relates.

The definition focuses on the relationship between the data and the individual. The person does not need to:

• own the database;

• create the data;

• provide the data directly;

• know that the data exists;

• possess the device;

• be a customer; or

• have a contract with the Data Fiduciary.

Example

Examples include:

• an employee discussed in a disciplinary email;

• a customer shown in CCTV footage;

• a child appearing in a photograph;

• a director named in company records;

• a guarantor in a loan file;

• a job candidate ranked by software;

• a delivery worker recorded by a door camera;

• a patient mentioned in a laboratory report;

• a witness named in litigation documents; and

• a person assigned a fraud-risk score.

13.1 Data Principal is not “data owner”

The DPDPA does not describe the individual as owning personal data like property. Personal data can involve competing interests, legal obligations and information about several individuals.

Example

For example, an email between two employees may contain personal data relating to:

• the sender;

• recipient;

• customer;

• colleague discussed;

• witness;

• manager; and

• family member mentioned.

Each can be a Data Principal in relation to different parts of the same record.

13.2 Data relating to several persons

A joint bank account record relates to both account holders. A family insurance policy may relate to the employee, spouse, children and nominee. A complaint may relate to the complainant, accused employee and witnesses.

Rights must therefore be handled carefully so that responding to one Data Principal does not improperly disclose another person’s data.

14. Section 2(j)(i): Child

Where the individual is a child, “Data Principal” includes the parent or lawful guardian.

The child remains the individual to whom the data relates. The parent or guardian is included so that relevant acts can be performed for the child within the statutory framework.

This does not mean:

• the parent becomes the subject of all the child’s data;

• the child’s data becomes the parent’s property;

• every adult claiming to be a parent can act;

• one parent can necessarily override a lawful custody restriction; or

• the child ceases to have privacy interests.

The organisation must establish the appropriate parental or guardianship relationship in accordance with the Rules and the context.

Illustration

A fourteen-year-old uses an educational platform. Her learning history is personal data relating to her. Her parent may act within the statutory consent framework, but the parent is not the underlying subject of the learning profile.

15. Section 2(j)(ii): Person with disability

Where an individual is a person with disability, the definition includes her lawful guardian acting on her behalf.

Three limits are built into the wording:

1. there must be a lawful guardian;

2. the guardian must act on behalf of the person;

3. inclusion is connected to the person’s disability and lawful representation.

The definition should not be read as declaring every person with disability incapable of acting independently. Disability and legal incapacity are not equivalent. An organisation should not route a capable adult’s privacy choices through a relative merely because the person has a disability.

15.1 Illustration 1: Accessible interface

A visually impaired adult can independently use an accessible consent interface. The company should deal directly with her. Her disability does not justify substituting a family member.

15.2 Illustration 2: Lawful guardianship

An adult with a legally recognised guardian cannot independently manage the relevant decision. The guardian acts on her behalf within the scope of lawful authority.

15.3 Illustration 3: Informal caregiver

A sibling routinely assists a person with disability but has no legally recognised guardianship or authority. The sibling does not automatically become included in the statutory definition.

15.4 GDPR comparison

The GDPR uses “data subject” for the identified or identifiable natural person. It does not generally redefine the data subject to include parents or guardians. Representation is handled through applicable national law and specific consent rules. The DPDPA expressly includes the parent or lawful guardian in the defined expression in the stated circumstances.

16. Section 2(k): “Data Processor”

A Data Processor is any person who processes personal dataon behalf of a Data Fiduciary.

Two elements are central:

1. there is processing of personal data; and

2. it is undertaken on behalf of a Data Fiduciary.

16.1 “On behalf of”

The Processor serves the Data Fiduciary’s purpose. It does not independently decide to use the data for another purpose.

Processor activities commonly include:

• cloud hosting;

• payroll administration;

• outsourced customer support;

• document scanning;

• managed security;

• email distribution;

• CRM hosting;

• records destruction;

• data-entry services;

• call recording;

• background-verification steps under detailed instructions; and

• outsourced data-subject request support.

16.2 Separate entity issue

Unlike the EDPB’s formulation, the DPDPA definition does not expressly state that a Processor must be a separate entity. However, “on behalf of a Data Fiduciary” ordinarily contemplates another person performing the processing.

An internal department is normally part of the same Data Fiduciary rather than a separate Data Processor. Employees acting within authority process data for the organisation, not as separate statutory vendors.

16.3 Independent purposes destroy Processor status for that use

If the vendor uses entrusted data to:

• train its own commercial model;

• build a cross-client database;

• sell leads;

• advertise its own services;

• perform unrelated research; or

• create independent profiles, it becomes a Data Fiduciary for that additional processing.

The role changes only for the relevant operations. It can remain a Processor for the instructed service.

16.4 DPDPA contractual framework

The DPDPA places responsibility on the Data Fiduciary for processing undertaken on its behalf. Section 8 requires engagement of a Data Processor under a valid contract where the Data Fiduciary uses one to process personal data on its behalf.

The DPDPA does not reproduce GDPR Article 28’s full list of mandatory processor-contract terms. A sound Indian processing agreement should nevertheless address:

• purposes;

• processing operations;

• data categories;

• Data Principals;

• instructions;

• confidentiality;

• security;

• breach escalation;

• assistance with rights;

• retention and deletion;

• subprocessors;

• audit information;

• government requests;

• return of data;

• business continuity; and

• restrictions on independent use.

The uploaded practice note correctly warns that the contract must follow the actual fiduciary-processor, fiduciary-fiduciary or joint-fiduciary relationship rather than a generic template.

16.5 GDPR comparison

The GDPR gives processors several direct statutory duties, including Article 28 contractual obligations, records, security, breach escalation, subprocessor requirements and certain liability exposure.

The DPDPA’s structure places more concentrated accountability on the Data Fiduciary, though processors remain exposed through contracts, cybersecurity laws and any processing for which they themselves determine purpose and means.

17. Section 2(l): “Data Protection Officer”

A Data Protection Officer is an individual appointed by a Significant Data Fiduciary under Section 10(2)(a).

The statutory DPDPA role is therefore narrower than the everyday use of “DPO.”

An ordinary Data Fiduciary may voluntarily appoint a privacy officer and call that person a DPO internally. But the defined statutory office in Section 2(l) is linked to appointment by a Significant Data Fiduciary under Section 10.

The DPO must be an individual, not a committee or company. External support may be used, but the statutory appointment must identify an individual.

17.1 GDPR comparison

Under the GDPR, controllers and processors must designate a DPO in specified circumstances, including certain public-authority processing, regular and systematic monitoring on a large scale and large-scale processing of special-category or criminal-offence data. Under the DPDPA, the statutory DPO obligation is tied to Significant Data Fiduciary designation rather than the GDPR’s direct activity-based triggers.

18. Section 2(m): “Digital office”

A digital office is an office adopting an online mechanism through which proceedings are conducted digitally from receipt to disposal.

The definition covers the full proceeding lifecycle:

• receipt of an intimation;

• complaint;

• reference;

• direction;

• appeal, where applicable;

• procedural steps; and

• final disposal.

A digital office is more than accepting email. The statutory idea is an end-to-end digital proceeding.

Practical requirements include:

• secure filing;

• identity verification;

• electronic records;

• notice delivery;

• online hearings;

• submission of evidence;

• access control;

• digital orders;

• audit trails; and

• accessibility.

18.1 GDPR comparison

The GDPR does not define an equivalent “digital office.” Procedures are administered through national supervisory and judicial systems.

19. Section 2(n): “Digital personal data”

Digital personal data means personal data in digital form.

This definition combines:

• personal data under Section 2(t); and

• a digital form.

Example

Examples include:

• scanned Aadhaar documents;

• CCTV recordings;

• customer emails;

• spreadsheet records;

• biometric templates;

• application logs;

• digital photographs;

• call recordings;

• location histories;

• electronic patient records; and

• manually typed summaries of paper forms.

A paper document is not digital personal data merely because it can be digitised. Once it is scanned, photographed or transcribed digitally, the digital representation becomes digital personal data.

19.1 GDPR comparison

The GDPR’s material scope also covers structured non-digital filing systems. The DPDPA’s material scope is narrower because it centres digital personal data.

19.2 Sections 2(o) and 2(p): “Gain” and “loss”

19.3 “Gain”

Gain includes:

1. gain in property or supply of services, temporary or permanent; and

2. an opportunity to earn remuneration, greater remuneration or another financial advantage, except legitimate remuneration.

19.4 “Loss”

Loss includes:

1. loss of property or interruption in services, temporary or permanent; and

2. loss of an opportunity to earn remuneration, greater remuneration or another financial advantage, except legitimate remuneration.

These definitions are broader than a completed transfer of money.

19.5 Temporary gain or loss

Example

Examples include:

• temporary access to a paid service through stolen credentials;

• temporary freezing of a bank account;

• temporary interruption of mobile service;

• temporary loss of account access; and

• temporary use of another person’s subscription.

19.6 Opportunity-based harm

A person may suffer loss where false personal data causes:

• rejection from employment;

• denial of promotion;

• denial of credit;

• loss of an insurance opportunity; or

• removal from a commercial tender.

The corresponding wrongdoer may gain an opportunity even without immediately receiving money.

19.7 Legitimate remuneration qualification

Ordinary salary, professional fees or contractual payment are not wrongful “gain” merely because they are financial advantages. The phrase excludes legitimate remuneration from the second limb.

19.8 GDPR comparison

The GDPR does not contain equivalent general definitions of gain and loss. Its remedial framework refers to material and non-material damage, while administrative fines focus on infringement. The DPDPA’s definitions are linked to its specific statutory uses and should not be equated with GDPR “damage.”

20. Section 2(q): “Member”

A Member means a Member of the Board and includes the Chairperson.

The definition avoids repetition throughout the institutional provisions. Where an obligation or restriction applies to a Member, it ordinarily applies to the Chairperson unless the context requires otherwise.

21. Section 2(r): “Notification”

A notification is one published in the Official Gazette. “Notify” and “notified” have corresponding meanings.

A website announcement, press release, ministerial speech, FAQ or social-media statement is not a statutory notification unless published in the Official Gazette in the required manner.

This matters for:

• commencement;

• designation of Significant Data Fiduciaries;

• statutory exemptions;

• cross-border restrictions;

• constitution and operation of institutions; and

• other delegated actions requiring notification.

Illustration

A ministry announces at a conference that a category of business will be treated as Significant Data Fiduciaries. Until the required Gazette notification is issued, the statutory designation is not completed merely by the public statement.

22. Section 2(s): “Person”

“Person” includes:

1. an individual;

2. a Hindu undivided family;

3. a company;

4. a firm;

5. an association of persons or body of individuals, incorporated or not;

6. the State; and

7. every other artificial juristic person not already listed.

This definition ensures that Data Fiduciaries and Data Processors can include public, private, incorporated and unincorporated actors.

22.1 Important implications

22.2 State bodies can be Data Fiduciaries

A ministry, municipality, statutory authority or other State entity may determine purposes and means and fall within the definition, subject to the Act’s applicable provisions and exemptions.

22.3 Business structure is irrelevant to basic coverage

A small partnership, HUF business or unincorporated association does not escape the Act merely because it is not a company.

22.4 Departments are ordinarily not separate persons

An organisation’s HR, finance or marketing department is usually not a separate Data Fiduciary because it lacks a distinct legal identity.

22.5 Corporate groups are not one person

Each group company is generally a separate person. Sharing data within a group is not equivalent to internal sharing within one legal entity.

23. Section 2(t): “Personal data”

Personal data means any data about an individual who is identifiable by or in relation to such data.

The definition contains three components:

1. there must be data;

2. it must be about an individual;

3. the individual must be identifiable by the data or in relation to it.

23.1 “Any data”

The definition is format-neutral at this stage. The DPDPA’s application is later restricted to digital personal data under Section 3.

23.2 “About an individual”

The information must relate to a natural person.

Example

Examples include:

• name;

• phone number;

• photograph;

• salary;

• medical condition;

• employee rating;

• transaction history;

• location;

• attendance;

• family information;

• complaint;

• voice recording;

• biometric template;

• online identifier;

• inferred preference; and

• risk score.

23.3 Direct identification

A person may be directly identifiable through:

• name;

• photograph;

• Aadhaar number;

• employee number linked to an HR record;

• mobile number;

• email address; or

• clear voice recording.

23.4 Indirect identification

A person may be identifiable through combinations such as:

• age, village and profession;

• job title and employer;

• device identifier and account activity;

• location pattern and workplace;

• rare medical condition and hospital;

• transaction history and account reference; or

• vehicle number and journey record.

23.5 “By or in relation to”

This language captures identification through the data itself or through its relationship with other available information.

A customer code such as “C-18427” may be meaningless to the public but personal data in the hands of a company able to link it to a customer.

23.6 Pseudonymised data

Replacing a name with a code does not necessarily make data non-personal where re-identification remains possible using a key or other information.

23.7 Anonymised data

Data genuinely transformed so that no individual is identifiable may cease to be personal data. Merely removing names is not enough where individuals remain identifiable through combinations or singling out.

23.8 Corporate information

Information solely about a company is not personal data. But company information can also relate to an individual.

Example

Examples:

• company revenue: generally not personal data;

• generic info@company.in: generally not personal data;

• named sole proprietor’s tax and bank details: personal data;

• director remuneration: personal data;

• employee email: personal data.

23.9 GDPR comparison

The GDPR definition refers to information “relating to” an identified or identifiable natural person and expressly mentions identifiers and identity factors. The DPDPA uses the formulation “about an individual who is identifiable by or in relation to such data.”

The concepts substantially overlap, but the DPDPA does not reproduce the GDPR’s detailed examples. GDPR interpretations can assist with identifiability, but the Indian statutory wording remains controlling.

24. Section 2(u): “Personal data breach”

A personal data breach means:

1. unauthorised processing of personal data; or

2. accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access, where the event compromises:

• confidentiality;

• integrity; or

• availability of personal data.

The definition covers the three classical information-security dimensions.

24.1 Confidentiality

Personal data is accessed or disclosed to an unauthorised person.

Example

Examples:

• an email sent to the wrong recipient;

• stolen credentials;

• unauthorised employee browsing;

• a public cloud folder;

• a lost unencrypted laptop; or

• customer records exposed through an API.

24.2 Integrity

Personal data is improperly changed or corrupted.

Example

Examples:

• salary data altered;

• a medical record modified;

• account details replaced;

• dates of birth corrupted;

• malware changing customer information; or

• inaccurate data imported through a faulty migration.

24.3 Availability

Personal data becomes inaccessible or is destroyed.

Example

Examples:

• ransomware encrypts records;

• backups fail;

• an employee deletes a database;

• system failure blocks access;

• a cloud account is wrongly terminated; or

• physical destruction removes the only digital copy.

24.4 Unauthorised processing is broader than disclosure

A breach can occur even without information leaving the organisation.

An employee who searches a celebrity’s customer profile out of curiosity engages in unauthorised processing. Confidentiality is compromised even if the employee does not share the information.

24.5 Accidental events count

Malicious conduct is not required. Human error, software failure and accidental deletion can qualify.

24.6 DPDPA versus GDPR

The definitions are broadly similar in protecting confidentiality, integrity and availability. The major difference lies in notification.

Under the GDPR:

• supervisory notification is generally subject to a risk threshold;

• individual notification generally requires likely high risk.

Under the DPDPA and final Rule 7, the notification framework does not reproduce those GDPR thresholds. The uploaded practice note correctly warns against copying a GDPR risk threshold into an Indian processor agreement.

25. Section 2(v): “Prescribed”

“Prescribed” means prescribed by rules made under the Act.

The word does not refer to:

• internal company policy;

• industry custom;

• a regulator’s informal statement;

• a contractual standard; or

• foreign guidance.

When a provision says that a matter will be “prescribed,” the legally relevant detail must be found in valid rules made under the Act.

The final DPDP Rules, 2025 are the principal rules instrument. References to the January 2025 instrument must distinguish the earlier draft from the final Rules notified in November 2025 and corrected in December 2025.

26. Section 2(w): “Proceeding”

A proceeding is any action taken by the Board under the Act.

The definition is broad enough to cover the Board’s statutory procedural actions and should be read with:

• the Board’s powers;

• procedural provisions;

• digital-office framework;

• principles of natural justice;

• voluntary undertakings;

• inquiry and adjudication; and

• appeal.

Not every correspondence with the Board necessarily amounts to a completed adjudication. “Proceeding” can include intermediate procedural action.

26.1 GDPR comparison

The GDPR does not contain an equivalent uniform definition. Enforcement proceedings depend substantially on national supervisory and procedural law.

27. Section 2(x): “Processing”

Processing, in relation to personal data, means a wholly or partly automated operation or set of operations performed on digital personal data.

It includes:

• collection;

• recording;

• organisation;

• structuring;

• storage;

• adaptation;

• retrieval;

• use;

• alignment;

• combination;

• indexing;

• sharing;

• disclosure by transmission;

• dissemination;

• otherwise making available;

• restriction;

• erasure; and

• destruction.

The word “includes” means the list is illustrative rather than exhaustive.

27.1 Operation or set of operations

Processing can be one act or an entire workflow.

Example

For example, a recruitment workflow may involve:

1. receiving a résumé;

2. extracting fields;

3. searching social media;

4. scoring the candidate;

5. sharing the résumé;

6. conducting verification;

7. recording interview feedback;

8. making an offer;

9. retaining unsuccessful applications; and

10. deleting records.

Roles may differ across stages.

27.2 “Wholly or partly automated”

The process need not be fully automated. Human involvement does not remove it.

A physical form manually entered into software becomes part of digital processing. A manager manually viewing a digital file performs a human operation within a digital processing environment.

27.3 Storage is processing

A cloud provider need not read data to process it. Storage itself is expressly included.

27.4 Deletion is processing

Erasure and destruction are not outside the law merely because they reduce data. A deletion instruction, backup purge or database destruction is a processing operation.

27.5 Restriction is processing

Marking a file so it cannot be used for ordinary purposes, while retaining it for litigation or legal compliance, is processing.

27.6 Disclosure and sharing

Disclosure can occur through:

• email;

• API;

• shared drive;

• messaging application;

• physical display of a digital record;

• dashboard access;

• remote-login credentials; or

• publication.

27.7 GDPR comparison

The GDPR’s definition is extremely broad and applies to automated processing and structured manual filing. The DPDPA’s definition is tied to digital personal data and wholly or partly automated operations. The DPDPA expressly includes indexing, while the GDPR provides a similarly non-exhaustive list of operations.

28. Section 2(y): “She”

“She,” when used in relation to an individual, includes an individual irrespective of gender.

The Act uses feminine pronouns as gender-inclusive drafting. It does not limit a right, duty or protection to women.

Thus:

• “her consent” includes the consent of any individual;

• “her personal data” includes every individual’s personal data;

• “she may withdraw” applies irrespective of gender identity.

This is a drafting rule, not a substantive classification of gender.

29. Section 2(z): “Significant Data Fiduciary”

A Significant Data Fiduciary is a Data Fiduciary, or class of Data Fiduciaries, notified by the Central Government under Section 10.

A business does not become an SDF merely because:

• it is large;

• it handles sensitive information;

• it is multinational;

• it has many users; or

• advisers describe it as high-risk.

A valid statutory notification is required.

Section 10 permits the Central Government to consider factors such as:

• volume and sensitivity of personal data;

• risk to Data Principal rights;

• potential impact on sovereignty and integrity of India;

• risk to electoral democracy;

• security of the State; and

• public order.

SDFs have additional obligations, including appointment of a DPO, an independent data auditor and periodic impact and audit measures as prescribed.

29.1 GDPR comparison

The GDPR has no designated class called “Significant Data Fiduciary.” Enhanced duties arise directly from processing circumstances, such as high-risk processing, large-scale special-category processing, systematic monitoring and the need for DPIAs or DPOs. The DPDPA uses governmental designation as the formal trigger for the SDF category.

30. Section 2(za): “Specified purpose”

A specified purpose is the purpose mentioned in the notice given by the Data Fiduciary to the Data Principal in accordance with the Act and Rules.

The definition links lawful processing to notice precision.

A purpose should explain the intended outcome, not merely name an internal department or repeat the word “processing.”

30.1 Weak purposes

• “business purposes”;

• “operational needs”;

• “improving services”;

• “commercial use”;

• “as necessary”;

• “analytics”; or

• “legal purposes.”

30.2 Better purposes

• processing address and phone number to deliver an order;

• processing bank details to reimburse employee expenses;

• processing identity records to complete vendor onboarding;

• processing applicant qualifications to assess suitability for a stated role;

• processing CCTV footage to secure specified premises and investigate security incidents;

• processing transaction data to detect and prevent payment fraud.

30.3 Purpose must match actual processing

If a notice states “order delivery,” the Data Fiduciary should not treat that as authorisation to:

• sell customer profiles;

• conduct unrelated credit scoring;

• train an identity model;

• share data with advertisers; or

• retain information indefinitely.

A processor cannot use the Fiduciary’s specified purpose as authority for an independent purpose of its own.

30.4 GDPR comparison

The GDPR requires personal data to be collected for specified, explicit and legitimate purposes and restricts incompatible further processing. The DPDPA’s “specified purpose” is textually tied to the purpose stated in the notice.

31. Section 2(zb): “State”

“State” has the meaning assigned under Article 12 of the Constitution of India.

Article 12 includes:

• the Government and Parliament of India;

• each State Government and State Legislature;

• local authorities; and

• other authorities within the constitutional definition.

The adoption of Article 12’s meaning connects the DPDPA with established constitutional doctrine concerning whether an entity is an instrumentality or authority of the State.

The definition matters because:

• State entities can be “persons”;

• State entities can be Data Fiduciaries;

• certain provisions and exemptions concern State functions;

• constitutional privacy and proportionality principles may operate alongside the Act; and

• government processing is not automatically outside the DPDPA merely because the processor is public.

Whether a particular body falls within Article 12 depends on constitutional law and the body’s legal and functional characteristics.

31.1 GDPR comparison

The GDPR refers to public authorities and bodies but does not incorporate a constitutional definition equivalent to Article 12 of the Indian Constitution.

31.2 Consolidated relationship matrix

31.3 Final interpretive principles

1. Roles belong to processing operations, not permanent labels.

A company may be a Data Fiduciary for one operation, a Data Processor for another and a joint Data Fiduciary for a third.

2. The actual facts prevail over the contract.

A processor clause cannot transform an independently acting law firm, bank, auditor or marketing data broker into a Processor.

3. Purpose is the strongest starting point.

Ask whose objective the processing serves.

4. Means remain essential.

The DPDPA requires determination of purpose and means. Choosing only routine technical implementation does not necessarily make a vendor a Data Fiduciary.

5. A vendor is not automatically a Processor.

The fact that personal data is handled while providing a service is insufficient. Taxi providers, banks, law firms, auditors and recruitment agencies may process data for their own independent purposes.

6. A shared database does not automatically create joint fiduciary status.

Joint status requires joint determination of purpose and means.

7. Data sharing does not itself create joint Data Fiduciaries.

Two independent Data Fiduciaries may disclose the same data to one another for separate purposes.

8. No access to the data is needed to be a Data Fiduciary.

Determinative influence can exist where an entity receives only aggregated outputs.

9. Joint status is operation-specific.

Parties can be joint Data Fiduciaries for a shared campaign but separate Data Fiduciaries for later customer management.

10. Joint responsibility need not be equal.

The parties may influence different elements and stages, but an allocation agreement cannot erase their statutory roles.

11. A Processor that develops its own purpose becomes a Data Fiduciary for that processing.

12. Internal staff are ordinarily not separate Processors.

The organisation remains the relevant statutory person while they act within authority.

13. Data Principal does not mean data owner.

The definition identifies the individual to whom the information relates.

14. One record may concern several Data Principals.

Access and correction must be managed without violating the rights of others.

15. GDPR guidance is comparative, not controlling.

Its factual illustrations are highly useful, but the final Indian classification and legal consequences must be anchored in Sections 2(i), 2(j), 2(k) and the wider DPDPA framework.