Section 7 - Certain legitimate uses

Key point

Clause-by-clause commentary on voluntary provision, State processing, legal obligations, judgments, emergencies, public health, disasters, employment, CCTV, artificial intelligence, marketing, scraping and related processing

1.1 Opening words: “A Data Fiduciary may process personal data of a Data Principal”

Section 7 begins by giving permission to a Data Fiduciary. It does not create a general power in favour of every recipient of personal data.

A Data Fiduciary is the person who determines, alone or together with another person, the purpose and means of processing. The analysis is factual. A company does not become a mere Data Processor simply because a contract describes it that way. If it independently decides why personal data will be used, it is acting as a Data Fiduciary for that operation.

The opening words contain four important limits.

First, Section 7 applies only after Section 3 brings the processing within the Act. Purely analogue records, qualifying personal or domestic processing and qualifying publicly available personal data may fall outside Section 3 before Section 7 is reached.

Second, Section 7 does not dispense with Section 4. The processing must still be for a lawful purpose, meaning a purpose not expressly forbidden by law.

Third, Section 7 does not remove the obligations imposed by the remainder of the Act. A Data Fiduciary relying on Section 7 must still consider:

• accuracy and completeness where applicable;

• reasonable security safeguards;

• processor contracts;

• breach notification;

• retention and erasure;

• grievance redressal;

• Data Principal rights;

• children’s-data requirements;

• Significant Data Fiduciary obligations;

• cross-border transfer restrictions.

Fourth, Section 7 operates clause by clause. A Data Fiduciary must identify the exact paragraph that permits the processing. It cannot simply write “legitimate use” in a data-processing register.

The correct structure is:

1. Does Section 3 apply?
2. Is the purpose lawful under Section 4?
3. Is there valid consent under Section 6?

• Yes: process within the scope of that consent.
• No: go to step 4.

4. Does the processing fit an exact Section 7 clause?

• No: the processing has no ground under the DPDPA.
• Yes: go to step 5.

5. Process only within the scope and conditions of that specific clause, while complying with the rest of the Act.

2. “May process”

The word “may” gives conditional permission. It does not impose a duty to process simply because a legitimate use is available.

A hospital may process information necessary to respond to a medical emergency. It is not required to collect every available piece of information about the patient.

An employer may process employee data to prevent theft. It is not automatically entitled to install every technically available surveillance system.

A government department may process data to perform a statutory function. It must still remain within the legal function and applicable constitutional and statutory limits.

The word “may” also leaves room for another law to prohibit or restrict the processing. Section 7 is a permission under the DPDPA, not a defence against every other Indian law.

Example

For example, Section 7 cannot by itself override:

• professional confidentiality;

• secrecy obligations;

• constitutional restrictions on State action;

• labour protections;

• sectoral disclosure limits;

• court-imposed confidentiality;

• evidentiary restrictions;

• restrictions on surveillance or interception.

3. “For any of the following uses”

The expression “the following uses” establishes a closed statutory list.

The DPDPA does not provide a general private-sector “legitimate interests” ground comparable to GDPR Article 6(1)(f). Under the GDPR, legitimate interests can support processing where three cumulative conditions are met:

1. a lawful, present and precisely articulated interest;

2. processing that is necessary to pursue that interest;

3. a balance showing that the individual’s rights and freedoms do not override the interest.

The EDPB’s 2024 guidance emphasises that a controller must conduct and document those three stages before relying on legitimate interests and must consider whether the objective can be achieved through less intrusive means.

Section 7 of the DPDPA is structurally different.

The EDPB’s necessity, proportionality and reasonable-expectation techniques are useful for interpreting the boundaries of Section 7. They cannot be used to invent an additional Indian ground.

Example

For example, an Indian company cannot justify general AI training by stating:

“Training the model serves our legitimate commercial interest and creates low privacy risk.”

Unless the processing fits Section 7(a) to 7(i), or is based on valid consent, that commercial-interest reasoning does not provide a DPDPA ground.

An organisation may issue a combined privacy notice covering consent and legitimate uses. It should clearly identify which processing depends on consent and which processing does not.

A notice should not say:

“By working here, you consent to payroll, legal reporting, workplace security, emergency response and all other processing.”

That obscures Section 7(i) and creates a false impression that the employee can withdraw consent and stop mandatory employment processing.

A better notice would say:

“We process personal data necessary to administer your employment and protect the organisation from loss or liability under Section 7(i). We will separately request consent for optional activities such as external promotional photographs or voluntary research.”

4. Section 7(a): Voluntarily provided personal data

Section 7(a) permits processing:

for the specified purpose for which the Data Principal has voluntarily provided her personal data to the Data Fiduciary, where she has not indicated that she does not consent to its use.

This clause contains four cumulative elements:

1. the Data Principal provides personal data;

2. the provision is voluntary;

3. the data is provided for a specified purpose;

4. she has not indicated non-consent to use for that purpose.

Section 7(a) is not a general implied-consent clause. It is a legitimate use tied to an individual’s voluntary, purpose-specific action.

5. “Voluntarily provided”

The Data Principal must have taken an action that supplies the personal data to the Data Fiduciary for the relevant purpose.

Typical examples include:

• giving a phone number to receive a receipt;

• sending a CV for a vacancy;

• messaging a broker to find accommodation;

• sending account documents to resolve a complaint;

• giving an address for delivery;

• supplying bank details for a requested refund;

• sending medical details to a doctor when seeking treatment;

• submitting expense information for reimbursement;

• asking HR for an employment certificate.

The clause is much harder to apply where data is:

• collected secretly;

• observed without meaningful awareness;

• purchased from a broker;

• scraped from a platform;

• inferred by an algorithm;

• received from an unauthorised third party;

• generated through hidden tracking;

• obtained from a leaked database.

A person who visits a website does not thereby voluntarily provide every technical identifier collected through hidden software development kits.

A person who walks into a shop may voluntarily expose her physical presence in an ordinary sense, but whether she has “voluntarily provided” her image to a CCTV system for a specified security purpose remains unresolved.

6. “For the specified purpose”

The purpose must be communicated or objectively evident with sufficient clarity.

The pharmacy illustration is narrow:

• the customer supplies a mobile number;

• she asks for a receipt by message;

• the pharmacy may use the number to send that receipt.

The provision does not authorise:

• promotional messages;

• sale of the number;

• health-product profiling;

• insurance marketing;

• creation of a patient database;

• unrelated loyalty enrolment.

The purpose is not “pharmacy business.” It is sending the requested payment receipt.

The real-estate illustration is equally narrow:

• the individual asks the broker to identify rental accommodation;

• she supplies information for that request;

• the broker may use it to identify and communicate suitable properties.

The broker may need the person’s:

• preferred area;

• budget;

• contact details;

• accommodation requirements;

• move-in date.

The broker does not automatically need:

• complete contact list;

• political opinions;

• medical history;

• unrelated bank records;

• photographs of family members;

• precise continuous location.

7. “Has not indicated that she does not consent”

This is not equivalent to Section 6 withdrawal in every respect, though the practical effect can be similar.

Under Section 7(a), the Data Principal need not complete a formal withdrawal process. She may indicate that the assistance or use is no longer wanted.

The broker illustration confirms that after the person says she no longer needs help, the broker must cease processing for that purpose.

An indication of non-consent may be:

• “Stop sending properties”;

• “Do not use my number”;

• “I no longer need assistance”;

• an unsubscribe instruction;

• a request to close the enquiry;

• an objection communicated through the available channel.

The Data Fiduciary should not require the Data Principal to use legal terminology.

8. Section 7(a) is not a substitute for consent

Section 7(a) should not be used whenever Section 6 consent would be inconvenient.

The clause is strongest where:

• the individual initiates the interaction;

• the purpose is concrete;

• the data is supplied directly for that purpose;

• the expected use is obvious and narrow;

• no hidden secondary processing occurs.

It is weaker where:

• the Data Fiduciary designs a mandatory flow;

• the service is essential;

• the individual cannot meaningfully avoid processing;

• extensive profiling occurs;

• data is obtained from third parties;

• the purpose is hidden;

• the organisation relies on inactivity.

9. Customer-facing activities

9.1 Case study 1: Hotel booking

A guest sends her name, contact number, stay dates and room preference to a hotel to reserve accommodation.

Section 7(a) can support processing necessary to:

• check availability;

• communicate rates;

• confirm the reservation;

• prepare for the stay.

It does not automatically permit:

• adding the guest to promotional broadcasts;

• sharing her profile with luxury-product advertisers;

• training a general guest-behaviour model;

• indefinite retention.

9.2 Case study 2: Restaurant reservation

A diner gives her phone number and dietary preference for a reservation.

The restaurant may use the information to manage the booking. The dietary entry should not automatically be converted into a health profile or advertising segment.

9.3 Case study 3: Customer complaint

A telecom customer sends account details and supporting records to dispute a bill.

The company may investigate and address the complaint. The records should not be used automatically to train a vendor’s general commercial AI model.

10. Marketing

Section 7(a) distinguishes transactional communication from marketing.

A business should not describe every message sent to an existing customer as “service communication.”

If a customer asks a broker to show rental properties, communicating suitable listings falls within the specified purpose. Sending insurance advertisements may not.

11. Applicants and potential candidates

A direct applicant who submits a CV for a named vacancy voluntarily supplies personal data for that recruitment purpose.

Section 7(a) can support:

• receiving the application;

• assessing qualifications;

• sharing the CV with relevant interviewers;

• scheduling interviews;

• communicating the outcome.

It does not automatically support:

• indefinite future retention;

• unrelated group-company circulation;

• training a reusable recruitment AI;

• commercial marketing;

• unrelated background investigation.

11.1 Passive candidate

A recruiter scrapes a public professional profile before the person expresses interest. The person has not voluntarily supplied data to that recruiter for that vacancy. Section 7(a) does not initially apply.

If the person replies and sends a CV, Section 7(a) may then support the interaction for the named opportunity.

11.2 Employee referral

An employee forwards a friend’s CV without the friend’s knowledge. The friend has not voluntarily supplied the CV to the employer. HR should contact the person before substantive processing.

11.3 Historical applicant AI training

An employer uses rejected applicants’ CVs and interview scores to train a ranking model. Those applicants supplied the information to be considered for jobs, not necessarily to develop a commercial or reusable model. Section 7(a) is unlikely to extend automatically to training.

12. Employees under Section 7(a)

Employees may voluntarily provide personal data for specific requests, even though core employment processing relies on Section 7(i).

Example

Examples include:

• requesting an employment certificate;

• submitting reimbursement information;

• asking to enrol a dependent in insurance;

• filing a grievance;

• seeking relocation assistance;

• requesting visa support.

Section 7(a) and Section 7(i) may overlap. The overlap does not authorise unrelated use.

An employee who supplies spouse information for insurance has not authorised marketing to the spouse.

13. CCTV under Section 7(a)

Commercial CCTV is one of the most difficult applications of Section 7(a).

The argument is:

1. clear CCTV signage is displayed before entry;

2. the individual sees the specified security purpose;

3. the individual voluntarily enters;

4. the resulting image is processed for that notified purpose;

5. the individual has not indicated non-consent.

The difficulty is that entering premises is not obviously the same thing as voluntarily providing personal data to the Data Fiduciary.

The Section 7(a) argument is strongest where:

• entry is genuinely optional;

• signage appears before capture;

• cameras are visible;

• the purpose is ordinary premises security;

• no audio is recorded;

• no facial recognition is used;

• the field of view is proportionate;

• no private space is covered.

It is weak where:

• the individual enters a hospital in an emergency;

• the surveillance starts before notice;

• cameras are hidden;

• entry is unavoidable;

• behavioural analytics operates;

• the footage is used for advertising;

• the operator performs facial recognition.

CCTV signage is transparency. It is not automatically Section 6 consent.

14. Section 7(b): State Benefits, Services, Certificates, Licences and Permits

Section 7(b) permits personal data to be processed for the State or any of its instrumentalities to provide or issue a qualifying:

• subsidy;

• benefit;

• service;

• certificate;

• licence; or

• permit.

The provision does not give the State an unrestricted power to reuse personal data. It applies only when the processing is genuinely connected with delivering one of the specified public items, one of the two gateways in Section 7(b)(i) or 7(b)(ii) is satisfied, and the standards in Rule 5 and the Second Schedule are followed.

Commencement: Section 7, Rule 5 and the Second Schedule are scheduled to become operational on13 May 2027, eighteen months after publication of the relevant Gazette notifications on 13 November 2025.

15. Structure of Section 7(b)

The provision operates through two alternative gateways:

15.1 Gateway 1: Previous consent

The Data Principal previously consented to the processing of her personal data by the State or an instrumentality of the State for any subsidy, benefit, service, certificate, licence or permit.

15.2 Gateway 2: Notified State record

The personal data is available:

• in digital form; or

• in a non-digital State record which is subsequently digitised, in a database, register, book or other document that:

• is maintained by the State or its instrumentality;

• has been notified by the Central Government; and

• is governed by an applicable Central Government personal-data policy or another law.

These gateways are alternatives. The State need not satisfy both, but it must clearly identify which gateway supports the particular processing.

16. “For the State and any of its instrumentalities”

Section 7(b) is a public-sector ground. It is available where the processing is undertaken for:

• the State, as understood through Article 12 of the Constitution; or

• an instrumentality of the State.

This may include Central and State Government departments, local authorities, statutory bodies and other entities that qualify as State instrumentalities under constitutional principles.

16.1 Private contractors

A private contractor does not become an instrumentality of the State merely because it:

• wins a government tender;

• develops a government application;

• operates a welfare portal;

• stores government records;

• verifies applications; or

• receives government funding.

A private technology provider may instead act as a Data Processor on behalf of a State Data Fiduciary.

16.2 Illustration: Pension portal

A Social Welfare Department appoints a technology company to operate a pension portal. The Department decides:

• eligibility criteria;

• required personal data;

• databases to be consulted;

• application workflow;

• retention;

• grievance procedures; and

• payment rules.

The technology company hosts the portal and applies the Department’s instructions.

The Department is the Data Fiduciary. The technology company is its Data Processor. Section 7(b) supports the Department’s qualifying public-purpose processing, not an independent commercial use by the technology company.

If the company uses pensioner data to market loans, train a commercial model or build consumer profiles, it becomes a Data Fiduciary for that additional processing and cannot rely on Section 7(b) merely because the data came from a government programme.

17. “To provide or issue”

The processing must be directed towards actually providing or issuing a qualifying public item to the Data Principal.

It may cover operations reasonably necessary to:

• receive an application;

• verify identity;

• assess eligibility;

• validate supporting information;

• check duplication;

• calculate the amount of a benefit;

• issue a certificate or licence;

• make payment;

• communicate the outcome;

• correct an issued record;

• renew or revoke an instrument;

• handle a grievance; or

• investigate fraud directly connected with the programme.

Section 7(b) does not authorise the State to create a general citizen-data repository merely because the information might later support public administration.

17.1 Meaning of the six categories

17.2 Subsidy

A subsidy ordinarily reduces a financial burden or supports a particular activity through public funds.

Example

Examples include:

• agricultural-input subsidy;

• housing subsidy;

• electricity subsidy;

• LPG subsidy; and

• interest subsidy.

17.3 Benefit

“Benefit” is wider than subsidy and may include:

• pension;

• maternity benefit;

• scholarship;

• disability support;

• health coverage;

• food-security entitlement; and

• social-security assistance.

17.4 Service

A service may include a public-health, educational, municipal or citizen-administration service. However, “service” should not be interpreted as covering every governmental activity. The service must be provided to the Data Principal.

17.5 Certificate

A certificate records or verifies a recognised status, fact or qualification, such as:

• birth or death;

• income;

• domicile;

• caste;

• disability;

• marriage; or

• educational qualification.

17.6 Licence

A licence usually authorises an activity that requires governmental approval, such as:

• driving;

• carrying on a regulated business;

• operating an establishment; or

• performing a regulated professional activity.

17.7 Permit

A permit ordinarily authorises a particular activity, use, construction, movement or event subject to stated conditions.

18. What does “as may be prescribed” cover?

Rule 5 gives effect to this requirement by covering subsidies, benefits, services, certificates, licences and permits that are provided or issued:

1. under a law;

2. under a policy or instruction of the Central or State Government issued in exercise of executive power; or

3. using public funds or involving receipts accruing to specified public funds.

The Rules do not provide a closed list naming every individual scheme. The State entity should therefore document the applicable statutory, policy or public-funding foundation for the programme.

A scholarship established by government policy and financed through public funds may qualify. A government officer’s informal or unauthorised initiative should not be treated as a prescribed public programme merely because it appears beneficial.

19. Section 7(b)(i): Previous consent

Section 7(b)(i) applies where the Data Principal previously consented to processing by the State or its instrumentality for any qualifying subsidy, benefit, service, certificate, licence or permit.

The earlier consent need not necessarily concern the exact benefit now being offered. This is confirmed by the statutory maternity-benefit illustration, which permits existing personal data to be used to determine eligibility for another prescribed benefit.

19.1 The earlier consent is a gateway, not blanket consent

The correct legal analysis is:

1. the individual previously gave valid consent for State processing connected with a qualifying public item;

2. that historical consent activates Section 7(b)(i);

3. Section 7(b) becomes the legal ground for the later processing;

4. the later processing must itself concern another qualifying public item;

5. the Data Principal must receive the intimation required by the Second Schedule; and

6. necessity, accuracy, retention, security and accountability requirements continue to apply.

The State should not tell the individual that she consented to every future government use. The later processing rests on a statutory legitimate use, not on an unlimited interpretation of the earlier consent.

19.2 Nature of the previous consent

The State should be able to show that the earlier consent related to:

• processing of personal data;

• by the State or one of its instrumentalities; and

• for a qualifying subsidy, benefit, service, certificate, licence or permit.

A compulsory statutory filing should not automatically be relabelled as consent. For example, a person who was legally required to submit tax information did not necessarily consent to its reuse for an unrelated welfare programme.

19.3 Withdrawal of the earlier consent

The Act does not clearly state whether an earlier consent must remain active when Section 7(b)(i) is later used. The words “has previously consented” support a historical reading, but reliance on consent that the individual expressly withdrew creates a genuine interpretive difficulty.

The safer approach is to:

• examine the scope and effect of the withdrawal;

• avoid treating withdrawn consent as continuing permission;

• issue a clear intimation before new processing;

• provide an effective avenue for correction and grievance;

• use only data necessary for the new benefit; and

• avoid adverse action based solely on stale information.

19.4 Case study 1: Maternity benefit and nutrition support

Anita enrols in a State maternity-benefit programme. She gives her name, age, address, bank details, expected delivery date, income category and consent for processing related to the programme.

The Government later introduces a prescribed postnatal nutrition benefit.

The Department uses Anita’s existing information to identify that she may be eligible. Before further processing, it sends her an intimation identifying:

• the nutrition programme;

• the data proposed to be used;

• the responsible Department;

• the contact person;

• the link for exercising rights; and

• the method for correcting outdated information.

The Department may rely on Section 7(b)(i), provided it uses only necessary data and verifies any information that may have changed after the maternity application.

It should not automatically assume that:

• Anita has delivered a child;

• her bank account remains active;

• her income remains unchanged; or

• her address remains correct.

19.5 Case study 2: Driving licence and road-safety service

Rohan previously consented to a State transport authority processing his personal data for a prescribed driving-licence service.

The authority later introduces a prescribed digital service that reminds drivers of licence expiry and permits online renewal.

The authority may use necessary licensing data to provide the renewal service under Section 7(b)(i). It should not use the same gateway to disclose Rohan’s details to vehicle dealers or insurance advertisers.

Renewal reminders and commercial vehicle advertising are different purposes.

19.6 Case study 3: Scholarship and unrelated policing

A student previously consented to processing for a government scholarship. A police unit seeks to use the scholarship database to identify families associated with political protests.

Section 7(b)(i) does not support this use. The proposed processing is not directed toward providing or issuing a subsidy, benefit, service, certificate, licence or permit. A separate statutory authority and legal ground would be required.

20. Section 7(b)(ii): Notified State database, register, book or document

The second gateway applies where the relevant personal data is available:

• in digital form; or

• in a non-digital record subsequently digitised, from a database, register, book or other document that is:

1. maintained by the State or its instrumentality; and

2. notified by the Central Government.

20.1 Notification is essential

Section 7(b)(ii) does not cover every record held by every government body. The particular database, register, book or document must be notified.

A department should not assume that the following are automatically covered:

• all departmental records;

• every State data lake;

• all legacy registers;

• information obtained from another ministry;

• court records;

• police records;

• land records; or

• local-government records.

The notification should be checked for:

• the identity of the record;

• the maintaining authority;

• the scope of data covered;

• any stated purposes;

• applicable conditions; and

• the date on which it takes effect.

20.2 “Maintained by”

The record must be maintained by the State or an instrumentality. A database hosted by a private cloud provider may still be maintained by the State where the State determines its contents, purposes, access and governance.

By contrast, a private company’s commercial database does not become a State database merely because a department obtains access to it.

20.3 Digitisation of physical records

The gateway can apply to data taken from a physical government register and subsequently digitised. Relevant examples may include:

• historical birth registers;

• land records;

• licence books;

• pension registers; or

• municipal records.

Digitisation does not remove the need for:

• notification;

• lawful purpose;

• necessity;

• accuracy checks;

• retention controls; and

• security.

Old paper records may contain outdated names, addresses, marital status, income or eligibility information. Conversion into digital form does not make them reliable.

20.4 Case study 1: Scholarship eligibility

A State education department administers a prescribed scholarship. The Central Government has notified specified education and income databases maintained by State authorities.

The department processes:

• student identity;

• enrolment status;

• household income;

• existing scholarship status; and

• bank information to determine eligibility and prevent duplicate payments.

Section 7(b)(ii) may apply where:

• the databases fall within the notification;

• the scholarship is prescribed;

• only necessary data is used;

• the student receives the required intimation;

• outdated income information can be corrected; and

• the decision process respects applicable law.

The department should not import unrelated health, travel or property data merely because those records are technically available elsewhere in government.

20.5 Case study 2: Unnotified citizen data lake

A State department creates a data lake combining:

• health records;

• school records;

• property ownership;

• transport history;

• welfare participation;

• electricity use; and

• family relationships.

It uses the combined database to assign a “welfare-fraud risk score.”

Section 7(b)(ii) does not automatically support this activity merely because the source records are held by public authorities.

The department must establish:

• that the relevant databases or documents have been notified;

• that the processing is directed toward a prescribed public item;

• that each field is necessary;

• that the scoring system is accurate and lawful;

• that affected individuals receive an intimation;

• that there is a correction and grievance pathway; and

• that the processing complies with the Second Schedule and applicable law.

Broad technical availability is not the statutory test.

20.6 Case study 3: Old municipal birth register

A municipality digitises a birth register from 1985. The register contains handwritten names, parent details, addresses and annotations.

The Central Government has notified the relevant class of registers for issuing digital birth certificates.

The municipality may use the digitised information to process certificate requests under Section 7(b)(ii). However, where handwriting is unclear or information conflicts with later records, the authority must make reasonable efforts to verify accuracy before issuing the certificate.

An OCR output should not be treated as conclusive merely because it was generated from an official record.

21. Second Schedule standards

Rule 5 requires Section 7(b) processing to follow the Second Schedule. These standards convert Section 7(b) from a broad permission into a controlled public-processing framework.

22. Lawfulness

Processing must be carried out lawfully.

Section 7(b) provides a DPDPA ground, but the underlying administrative action must also comply with:

• the governing statute;

• executive policy;

• constitutional requirements;

• administrative law;

• applicable sectoral rules;

• court orders; and

• any other relevant law.

Section 7(b) does not cure an unlawful eligibility rule, discriminatory programme or unauthorised administrative decision.

23. Purpose restriction

Processing must be undertaken for:

• the uses specified in Section 7(b); or

• the separate exempted purposes under Section 17(2)(b), where applicable.

A welfare database cannot be repurposed for political outreach, commercial advertising or unrelated surveillance merely because the State lawfully collected the data.

23.1 Proper use

Using pension records to prevent duplicate pension payments.

23.2 Improper reliance on Section 7(b)

Using the same records to identify elderly voters for political messaging.

24. Necessity and data minimisation

Processing must be limited to personal data necessary for the relevant use or purpose.

The State should ask:

• Is each data field needed?

• Can eligibility be determined with less information?

• Is full document access necessary?

• Is a yes-or-no eligibility signal sufficient?

• Is historical information still relevant?

• Is continuous access necessary?

• Does the department need a copy or only verification?

Example

A department assessing eligibility for an age-based travel benefit may need age and identity verification. It does not automatically need detailed medical history, complete bank transactions or family communications.

Availability within a notified database does not make every field necessary.

25. Accuracy

The State must make reasonable efforts to ensure the accuracy of personal data.

Accuracy is especially important where processing leads to:

• denial of a pension;

• cancellation of a ration entitlement;

• rejection of a scholarship;

• refusal of a certificate;

• suspension of a licence;

• recovery of money; or

• classification as a suspected duplicate or fraudulent claimant.

Reasonable efforts may include:

• checking the source and update date;

• reconciling conflicting records;

• allowing the Data Principal to correct information;

• marking disputed fields;

• avoiding automatic reliance on uncertain matches;

• human review of adverse outcomes; and

• recording the source of amendments.

Accuracy must include contextual accuracy. A record may have been accurate when collected but no longer represent the individual’s current circumstances.

26. Retention

Personal data may be retained:

• while required for the qualifying use or purpose; or

• where retention is required by law.

The Schedule does not authorise indefinite storage merely because the data belongs to the Government.

The State Data Fiduciary should establish:

• the active processing period;

• the statutory record-retention period;

• the grievance and appeal period;

• the audit period;

• archival requirements;

• deletion or anonymisation rules;

• treatment of backups; and

• responsibility for approving extensions.

Different records may require different periods. An issued licence, rejected application, fraud investigation and temporary eligibility document should not automatically share one indefinite retention period.

27. Reasonable security safeguards

The State Data Fiduciary must protect personal data in its possession or control, including processing undertaken on its behalf by a Data Processor.

Safeguards should address:

• access controls;

• encryption;

• identity and authentication;

• logging;

• database segregation;

• secure APIs;

• vulnerability management;

• backup;

• incident response;

• employee access;

• contractor access;

• secure digitisation;

• transmission;

• physical security;

• deletion; and

• regular testing.

The State remains accountable where a private technology provider processes the data on its behalf. Outsourcing the portal does not outsource statutory responsibility.

28. Intimation to the Data Principal

When processing is undertaken under Section 7(b), the State must give the Data Principal an intimation.

The intimation must include:

1. information about the processing;

2. business contact information of a person able to answer questions on behalf of the Data Fiduciary;

3. a specific link to the Data Fiduciary’s website or application through which rights may be exercised; and

4. information about any other available rights channel.

This is an intimation, not a request for fresh consent. The State is informing the individual that processing will occur under Section 7(b).

The intimation should clearly explain:

• the Data Fiduciary’s identity;

• the particular programme;

• the data involved;

• the source of the data;

• the purpose;

• significant decision-making involved;

• how to correct inaccurate data;

• where to raise a grievance;

• the responsible contact; and

• how rights can be exercised.

Providing a generic government privacy policy without identifying the programme and processing should not ordinarily be sufficient.

29. Additional policy and legal standards

Processing must remain consistent with:

• standards under a Central Government personal-data policy; and

• any applicable law.

Section 7(b), Rule 5 and the Second Schedule therefore operate as a minimum DPDPA framework. They do not replace stricter safeguards imposed by:

• sectoral legislation;

• programme rules;

• financial regulations;

• health laws;

• confidentiality requirements;

• constitutional principles;

• judicial directions; or

• applicable cybersecurity standards.

30. Accountability

The person who alone or in conjunction with others determines the purpose and means must be accountable for effective compliance with the Schedule.

This language follows the Data Fiduciary definition.

Accountability requires more than publishing a policy. The State Data Fiduciary should be able to demonstrate:

• the statutory gateway relied upon;

• the prescribed character of the benefit or instrument;

• the notification covering the source database;

• the data fields used;

• the necessity assessment;

• the applicable retention period;

• the accuracy process;

• the intimation delivered;

• processor contracts;

• security controls;

• audit trails;

• grievance handling; and

• decisions concerning automated systems.

Where two public authorities jointly determine a processing arrangement, both may be Data Fiduciaries acting in conjunction for the relevant operation.

31. Artificial intelligence under Section 7(b)

AI is not an independent lawful ground. The relevant ground remains Section 7(b).

AI may assist with:

• checking eligibility;

• identifying duplicate applications;

• matching applicants with benefits;

• detecting inconsistent records;

• prioritising applications;

• translating records;

• extracting data from physical documents; or

• identifying possible payment errors.

The same requirements apply whether the processing is performed by a clerk, rules engine or machine-learning model.

31.1 High-risk uses

Particular concern arises where AI:

• creates opaque eligibility scores;

• uses unrelated databases;

• infers caste, religion, disability, health or political preference;

• automatically rejects applications;

• relies on historical discrimination;

• treats database mismatch as proof of fraud;

• fails to accommodate name and address variations;

• uses inaccurate OCR;

• prevents meaningful correction; or

• produces outcomes officials cannot explain.

Section 7(b) may authorise the processing necessary for a benefit, but it does not automatically make the resulting administrative decision lawful, reasonable or constitutionally valid.

31.2 Case study: Automated pension cancellation

A pension authority matches a notified death register against beneficiary records. An automated system marks Kamla Devi as deceased because another person has a similar name and date of birth. Her pension is stopped without verification.

The processing may have a legitimate Section 7(b) objective, namely ensuring pension eligibility. But the implementation fails the accuracy standard and may violate administrative fairness.

A reasonable system should use:

• reliable identifiers;

• match-confidence thresholds;

• conflict checks;

• notice of adverse status;

• human verification;

• a rapid correction channel; and

• restoration of wrongly suspended benefits.

A lawful purpose does not excuse an unreliable decision process.

32. Political, commercial and law-enforcement reuse

Section 7(b) should not be treated as a general State-data-sharing provision.

32.1 Political messaging

A department cannot rely on Section 7(b) to provide beneficiary names and mobile numbers to a political party or campaign team. Political promotion is not the provision or issuance of the relevant benefit.

32.2 Commercial advertising

A transport authority cannot rely on Section 7(b) to sell driving-licence data to automobile dealers or insurers.

32.3 General law-enforcement profiling

A welfare department cannot rely on Section 7(b) to build unrelated criminal-risk profiles. A separate legal authority and DPDPA ground must be identified.

32.4 Public disclosure

The fact that a person received a benefit does not mean the State may publicly disclose:

• her financial hardship;

• health status;

• disability;

• pregnancy;

• caste;

• address;

• bank details; or

• family circumstances.

Any public-disclosure requirement must have its own lawful foundation and remain limited to the information required by law.

33. Practical compliance sequence

Before relying on Section 7(b), the State Data Fiduciary should answer the following:

Conclusion

Section 7(b) enables the State to deliver public benefits and administrative instruments without repeatedly obtaining fresh consent where personal data already exists through an earlier qualifying consent or a notified State record.

Its scope is nevertheless controlled by four important boundaries:

1. institutional boundary: the processing must be for the State or its instrumentalities;

2. purpose boundary: it must be directed toward providing or issuing a prescribed subsidy, benefit, service, certificate, licence or permit;

3. source boundary: either previous qualifying consent or a notified State record must support the processing; and

4. governance boundary: processing must comply with the Second Schedule’s lawfulness, necessity, accuracy, retention, security, intimation and accountability standards.

The provision facilitates connected public-service delivery. It does not create a general permission for the State to combine every citizen database, undertake unrestricted profiling or reuse welfare information for political, commercial or unrelated enforcement purposes.

34. Section 7(c): State functions, sovereignty, integrity and security

Section 7(c) covers processing by the State or its instrumentalities:

1. for performance of any function under any law in force in India; or

2. in the interest of sovereignty and integrity of India or security of the State.

This is a broad State-processing provision, but it is not textually unlimited.

35. “Performance of any function under any law”

The State must identify:

• the law;

• the function conferred or required by that law;

• the connection between the function and processing;

• the relevant State entity;

• the scope of personal data reasonably needed.

Example

Examples may include:

• tax administration;

• public-health functions;

• municipal administration;

• licensing;

• policing;

• regulatory supervision;

• land administration;

• electoral administration;

• public education;

• social-security administration.

The clause should not be reduced to:

“The Government may process anything because the Government has general functions.”

A lawful function must be identifiable.

36. Police processing

Police may process digital personal data for functions under criminal and police law, including:

• receiving complaints;

• investigating offences;

• identifying suspects;

• locating missing persons;

• maintaining case records;

• collecting digital evidence;

• operating authorised surveillance;

• responding to public-order threats.

Section 7(c) is the DPDPA ground. It does not itself create police power.

The police must obtain authority for:

• search;

• seizure;

• interception;

• access to private records;

• facial recognition;

• location tracking;

• database integration;

from the applicable substantive and procedural law.

Section 7(c) answers the data-protection-ground question. It does not answer whether the police were legally entitled to undertake the underlying surveillance or compel disclosure.

37. State CCTV

CCTV operated directly by:

• police;

• municipal bodies;

• transport authorities;

• public institutions;

• State instrumentalities;

may be processed under Section 7(c) where connected with a function under law or State security.

The analysis should distinguish:

37.1 Traffic enforcement CCTV

Cameras detect:

• red-light violations;

• speeding;

• vehicle numbers;

• lane violations.

The State should identify the legal traffic-enforcement function and restrict use accordingly.

Using the system to infer unrelated religious attendance, political participation or personal associations would require separate authority.

37.2 Railway or metro surveillance

CCTV may support passenger safety, prevention of crime and public-order functions.

The existence of a safety function does not automatically justify unlimited facial-recognition watchlists or indefinite retention.

37.3 Police facial recognition

Police may use facial recognition to identify a missing person or suspect. Section 7(c) may provide a DPDPA ground where the operation forms part of a lawful function.

Yet major issues remain:

• source and accuracy of the watchlist;

• false positives;

• proportionality;

• statutory authority;

• retention;

• access;

• treatment of innocent persons;

• use for peaceful public gatherings;

• auditability.

The DPDPA contains no detailed law-enforcement facial-recognition code. Section 7(c) should not be mistaken for that code.

38. Sovereignty, integrity and security of the State

These are high-level constitutional and public-law interests.

Processing may involve:

• counter-espionage;

• counter-terrorism;

• border security;

• national-security investigations;

• protection of defence information;

• cybersecurity of critical infrastructure.

The expressions should not be casually invoked for ordinary administrative convenience. “Security of the State” is not equivalent to:

• company security;

• municipal housekeeping;

• reputational management;

• suppression of criticism;

• routine employee monitoring.

The State should be able to identify the security connection and applicable legal authority.

39. GDPR comparison

Under the GDPR, Article 6(1)(e) permits processing necessary for a task in the public interest or exercise of official authority, while Article 6(1)(c) covers legal obligations. EU law also separates certain law-enforcement processing into a dedicated directive rather than relying solely on the GDPR.

The DPDPA contains no equivalent comprehensive law-enforcement directive. Section 7(c), Section 17 exemptions and other Indian laws must be read together.

40. Section 7(d): Legal obligation to disclose information to the State

Section 7(d) permits processing:

for fulfilling an obligation under Indian law on any person to disclose information to the State or its instrumentalities, provided the processing follows the legal provisions governing that disclosure.

This clause is narrower than the GDPR’s general “legal obligation” ground.

It requires:

1. an obligation under Indian law;

2. imposed on a person;

3. to disclose information;

4. to the State or its instrumentality;

5. processing consistent with the law governing disclosure.

41. It is not a general contract-performance ground

Section 7(d) does not cover:

• every contractual duty;

• every internal policy;

• every auditor request;

• every police inquiry;

• every demand letter;

• every vendor request.

The disclosure obligation must arise under law and must be owed to the State or a State instrumentality.

42. Employment reporting

Section 7(d) may apply where employers must disclose prescribed information to public authorities for:

• taxation;

• social security;

• provident-fund administration;

• labour reporting;

• inspection;

• workplace safety;

• immigration or foreigner reporting;

• regulatory filings.

The employer should identify the exact provision.

A general statement that all HR processing rests on Section 7(d) would be wrong. Payroll administration is primarily employment processing under Section 7(i), while specified disclosures to State authorities may fall under Section 7(d).

43. Financial institutions

Banks, insurers and regulated financial entities may have statutory disclosure duties relating to:

• tax reporting;

• suspicious transactions;

• anti-money-laundering requirements;

• regulatory supervision;

• court or enforcement processes;

• specified government reporting.

Section 7(d) does not permit disclosure beyond the categories, authority, process or purpose defined by the law.

44. CCTV mandated by public-safety law

Section 7(d) is highly relevant where State law requires covered establishments to:

• install CCTV;

• maintain recordings;

• retain footage;

• make footage available to designated authorities.

Where recording and retention are necessary steps toward fulfilling the statutory disclosure duty, Section 7(d) can support the mandated processing.

The ground is camera-specific and mandate-specific.

44.1 Covered

• required camera locations;

• required retention;

• prescribed format;

• authorised inspection;

• disclosure to specified police or public authority.

44.2 Not automatically covered

• facial-recognition advertising;

• customer analytics;

• employee productivity scoring;

• social-media publication;

• sale of footage;

• permanent retention;

• recording beyond mandated locations.

A business should record:

• exact State law;

• applicability threshold;

• notified area;

• camera location;

• prescribed retention;

• authorised recipient;

• disclosure procedure.

45. Police requests to private entities

A police request is not automatically a Section 7(d) obligation.

The recipient should verify:

• identity and authority of the requesting officer;

• statutory basis;

• whether an order or written request is required;

• scope;

• date range;

• persons concerned;

• confidentiality;

• preservation requirement.

A hotel should not disclose its entire guest database because an officer informally asks for “all records.” Section 7(d) requires compliance with the disclosure provisions of the mandating law.

46. AI for mandatory reporting

A bank may use an automated system to identify transactions potentially requiring statutory reporting.

The system’s purpose may fit the regulatory function, but the organisation should distinguish:

• internal risk detection;

• mandatory disclosure;

• independent commercial scoring.

Using reporting data to market high-risk financial products would not be covered by Section 7(d).

47. Section 7(e): Judgments, decrees and orders

Section 7(e) has two branches.

47.1 Indian branch

Processing is permitted for compliance with:

• a judgment;

• decree;

• order;

issued under Indian law.

47.2 Foreign civil or contractual branch

Processing is permitted for compliance with a foreign judgment or order relating to claims of:

• contractual nature; or

• civil nature.

The foreign branch is narrower in subject matter than the Indian branch.

48. “For compliance”

The processing must be connected with complying with the decision.

Example

Examples include:

• producing documents;

• implementing an injunction;

• paying court-awarded compensation;

• restoring employment;

• executing a decree;

• complying with a tribunal direction;

• preserving or disclosing specified records.

A judgment requiring disclosure of ten employee records does not authorise disclosure of the whole HR database.

49. Indian orders

The clause can cover orders of courts and bodies authorised under Indian law, depending on the nature of the issuing body and order.

The Data Fiduciary should verify:

• authenticity;

• jurisdiction;

• scope;

• operative directions;

• confidentiality;

• appeal or stay;

• deadline.

50. Foreign judgments and orders

The foreign component applies to civil or contractual claims.

Example

Examples may include:

• international commercial dispute;

• foreign contractual judgment;

• overseas civil discovery or disclosure order;

• enforcement-related documentation.

The clause does not state that every foreign criminal or administrative request is covered.

Compliance must also be reconciled with:

• Indian procedural law;

• confidentiality;

• public policy;

• privilege;

• cross-border transfer restrictions;

• enforceability.

51. Three case studies

51.1 Employee litigation

A labour court orders production of attendance and wage records for a named employee.

Section 7(e) supports processing required to comply. It does not authorise publishing the records.

51.2 Commercial arbitration order

A tribunal constituted under applicable law orders preservation and production of communications relevant to a contract dispute.

The company may process the specified records for compliance, subject to privilege and confidentiality.

51.3 Foreign civil claim

A foreign court orders an Indian company to produce records in a contractual action.

Section 7(e) may provide the DPDPA ground, but the company must still examine Indian legal restrictions and transfer requirements.

52. Section 7(f): Medical emergency

Section 7(f) permits processing for responding to a medical emergency involving:

• a threat to the life; or

• an immediate threat to the health;

of the Data Principal or any other individual.

This is an emergency ground. It should not become a general healthcare-processing basis.

53. “Medical emergency”

The situation must require immediate medical response.

Example

Examples include:

• unconscious accident victim;

• cardiac arrest;

• severe allergic reaction;

• acute mental-health crisis involving immediate danger;

• life-threatening workplace injury;

• emergency blood transfusion;

• urgent communication with medical responders.

Routine appointment scheduling is not a medical emergency.

General wellness analytics is not a medical emergency.

Insurance underwriting is not a medical emergency.

54. “Threat to life” and “immediate threat to health”

The word “immediate” restricts the health branch.

A long-term possibility of disease may justify medical advice, but it does not automatically create an emergency.

54.1 Case study 1: Unconscious hotel guest

A guest collapses at a hotel. Staff access the guest’s emergency contact and relevant medical information and share it with paramedics.

Section 7(f) may apply.

54.2 Case study 2: Employer wellness programme

An employer collects continuous health and lifestyle data from all employees to reduce future insurance costs.

This is not emergency processing. Consent or another ground is required.

54.3 Case study 3: AI emergency triage

A hospital uses an automated tool to prioritise patients in an emergency department.

Processing necessary for immediate triage may fall within Section 7(f). Reusing the data to train a commercial product is a separate purpose.

55. Data of another individual

The clause allows processing to protect someone other than the Data Principal.

Example

For example, information from a driver’s phone might be processed to contact a passenger’s family after an accident, where necessary.

The provision should remain tied to the emergency.

56. GDPR comparison

GDPR Article 6(1)(d) recognises processing necessary to protect vital interests. Health data may also require an Article 9 condition because the GDPR has a special-category regime. The DPDPA does not create an equivalent special-category structure.

The absence of a special category does not make health data low-risk. Security, necessity and restricted access remain critical.

57. Section 7(g): Epidemics, outbreaks and public-health threats

Section 7(g) permits processing to take measures to provide:

• medical treatment; or

• health services;

to any individual during:

• an epidemic;

• an outbreak of disease;

• another threat to public health.

This is broader than an individual emergency but limited by the public-health context and service purpose.

58. “Taking measures”

The phrase can include preparatory and operational actions reasonably required to provide treatment or health services, such as:

• identifying affected persons;

• scheduling testing;

• communicating treatment instructions;

• allocating medical resources;

• arranging vaccination;

• contact coordination;

• hospital capacity management;

• issuing public-health alerts targeted to affected persons.

It should not automatically include every research, commercial or surveillance activity associated with the event.

59. “Any individual”

The individual need not be the original Data Principal whose data is processed.

Example

For example, processing one person’s exposure history may help identify another person who needs treatment.

60. Public-health AI

AI may be used to:

• forecast hospital demand;

• identify persons needing treatment;

• allocate resources;

• analyse outbreaks.

Section 7(g) does not provide permanent permission to retain emergency datasets or repurpose them after the crisis.

60.1 Case study 1: Disease outbreak

A health authority processes patient contact information to organise testing and treatment during an outbreak.

Clause (g) may apply.

60.2 Case study 2: Commercial advertising

A pharmacy uses outbreak records to market supplements.

Marketing is not medical treatment or a health service under the emergency ground merely because the product is health-related.

60.3 Case study 3: Post-outbreak model training

A technology vendor retains identifiable emergency health records to develop a global commercial prediction product.

The public-health ground does not automatically extend to post-crisis commercial development.

61. Section 7(h): Disaster and breakdown of public order

Section 7(h) permits processing for taking measures to:

• ensure safety;

• provide assistance;

• provide services;

to any individual during:

• a disaster; or

• a breakdown of public order.

The statutory explanation adopts the Disaster Management Act, 2005 definition of disaster.

62. Disaster meaning

The incorporated definition covers serious events arising from natural or human causes, accident or negligence, resulting in substantial loss of life, human suffering, property damage or environmental harm and of a nature or magnitude beyond the coping capacity of the affected community.

Potential examples include:

• major flood;

• earthquake;

• cyclone;

• industrial chemical leak;

• building collapse;

• major fire;

• transport catastrophe;

• large-scale accident.

Not every inconvenience or local service interruption is a disaster.

63. Safety, assistance and services

The permitted processing may include:

• locating missing persons;

• identifying victims;

• arranging rescue;

• sending evacuation messages;

• allocating shelter;

• reconnecting families;

• providing food, medical aid or accommodation;

• coordinating emergency transport;

• protecting vulnerable persons.

64. Breakdown of public order

This expression may cover serious disturbances requiring safety or assistance measures.

It should not be equated with:

• ordinary protests;

• criticism of government;

• routine crowd management;

• commercial inconvenience.

The processing should remain connected with ensuring safety or delivering assistance.

65. Three case studies

65.1 Flood evacuation

A mobile network operator shares limited location data with an authorised disaster-management authority to locate persons trapped by floods.

Section 7(h) may support processing needed for rescue.

65.2 Hotel shelter

A hotel records identity and emergency needs of persons temporarily sheltered after a major fire.

The ground may support processing necessary to provide accommodation and assistance.

65.3 Post-disaster advertising

A company uses evacuation information to market property insurance.

That is not disaster assistance and requires another ground.

66. AI in disaster response

AI may assist in:

• identifying damaged areas;

• prioritising rescue;

• predicting resource needs;

• matching missing persons;

• assessing emergency communications.

The use must remain necessary to safety or assistance. Emergency necessity should not be used as a permanent justification for surveillance infrastructure.

67. Section 7(i): Employment and employer protection

Section 7(i) permits processing:

1. for purposes of employment;

2. for purposes related to safeguarding the employer from loss or liability;

3. for examples including prevention of corporate espionage and maintenance of confidentiality of trade secrets, intellectual property or classified information;

4. for provision of a service or benefit sought by an employee.

This is the central lawful ground for core employee processing.

68. “For the purposes of employment”

The phrase can cover processing genuinely connected with administering an existing employment relationship.

Example

Examples include:

• employee onboarding;

• payroll;

• attendance;

• leave;

• scheduling;

• performance assessment;

• training;

• promotion;

• transfer;

• disciplinary administration;

• workplace investigation;

• travel;

• access control;

• separation;

• final settlement;

• employment-related recordkeeping.

Consent should not be the default for such processing. An employee cannot meaningfully refuse payroll, basic attendance administration or necessary workplace records.

69. Applicants are not automatically employees

A potential candidate or applicant is ordinarily not an employee.

Section 7(a) may support a direct application for a named role. Consent should ordinarily support:

• background verification;

• future-talent-pool retention;

• psychometric testing;

• unrelated group sharing;

• training recruitment AI on the applicant’s data.

The phrase “purposes of employment” could be argued to include recruitment directed toward forming an employment relationship. However, a conservative interpretation separates pre-employment applicants from existing employees, especially because Section 7(a) directly covers voluntary submission.

70. Interns and trainees

An intern or trainee is not automatically an employee.

The legal and factual relationship depends on:

• applicable labour law;

• apprenticeship law;

• contract;

• control;

• payment;

• productive work;

• integration;

• programme purpose.

Where the person is not an employee, consent and Section 7(a) should ordinarily be used.

A company cannot avoid applicant or intern consent requirements by labelling everyone a future employee.

71. Safeguarding from loss or liability

This branch may support:

• theft prevention;

• fraud investigation;

• system-access logging;

• source-code security;

• trade-secret protection;

• unauthorised-download alerts;

• prevention of corporate espionage;

• investigation of confidential-data leakage;

• evidence preservation;

• protection of restricted areas;

• defence of legal claims.

The phrase “such as” indicates that the statutory examples are illustrative.

Yet “loss” should not be interpreted so broadly that every productivity concern becomes a surveillance justification.

An employer should document:

• specific risk;

• relevant data;

• connection with the risk;

• access;

• retention;

• alternative measures;

• limits on use.

72. Employee CCTV

Section 7(i) may support cameras protecting:

• cash rooms;

• server rooms;

• warehouses;

• restricted laboratories;

• entry and exit points;

• high-value inventory;

• confidential records.

It does not automatically support continuous recording in:

• washrooms;

• changing rooms;

• counselling rooms;

• prayer rooms;

• nursing rooms;

• highly private spaces.

Continuous desk monitoring merely to score productivity is harder to justify.

European enforcement illustrates the risk of overbroad workplace surveillance. In a 2024 Slovenian decision, CCTV monitoring workers in a restaurant kitchen and live broadcasting the footage on the company website were found unlawful. The authority concluded that the employer lacked an adequate legal basis and failed to meet transparency requirements. The decision is not binding in India, but it demonstrates why employer “interest” cannot justify unlimited monitoring.

73. Email, device and system monitoring

Section 7(i) may support proportionate monitoring designed to:

• detect malware;

• prevent data exfiltration;

• investigate unauthorised access;

• protect confidential information;

• maintain system security.

It should not automatically justify:

• reading all employee communications;

• monitoring private accounts;

• recording every keystroke indefinitely;

• analysing political or personal beliefs;

• monitoring outside work without a risk connection.

The purpose must remain employer protection or employment administration.

74. Employee AI

AI used for:

• payroll anomaly detection;

• access-security alerts;

• fraud investigation;

• protection of trade secrets;

may fit Section 7(i).

AI used for:

• emotion recognition;

• speculative personality scoring;

• private-life monitoring;

• commercial product development;

• sale of employee predictions;

requires a separate analysis.

74.1 Attrition prediction

An employer combines attendance, performance data and manager comments to predict resignation.

The employer may argue that workforce planning is an employment purpose. However, the more intrusive the data and consequences, the weaker a broad Section 7(i) claim becomes.

The assessment should ask:

• Is individual prediction necessary?

• Is the data accurate?

• Are private communications included?

• Does the model influence dismissal?

• Could aggregate analysis achieve the purpose?

• Is human review meaningful?

• Is the model biased?

Section 7(i) supplies a ground only if the processing genuinely remains an employment purpose. It does not validate unfair or inaccurate decision-making.

75. Services and benefits sought by employees

Example

Examples include:

• medical insurance;

• dependent coverage;

• transport;

• accommodation;

• relocation;

• salary advance;

• employment certificate;

• employee-assistance programme.

The employee must seek the service or benefit.

An employer cannot disclose payroll information for unsolicited bank marketing merely by describing loans as an employee benefit.

Information about spouses, children or nominees may relate to separate Data Principals. The employee’s request does not authorise unrelated processing of family information.

76. Post-employment

Section 7(i) may support some post-employment processing where closely connected with:

• final settlement;

• statutory records;

• employment claims;

• defence from liability;

• reference requests;

• protection of trade secrets.

It does not create a permanent right to retain all employee data.

An alumni marketing programme is not automatically an employment purpose. Consent may be required.

77. Marketing across Section 7

Section 7 does not contain a general marketing ground.

Marketing may fit Section 7(a) only where it is genuinely the specified purpose for which the person voluntarily provided data.

Example

Examples:

77.1 Likely within Section 7(a)

A person asks a property broker to send suitable listings. Sending those listings is the requested service.

A customer specifically asks to receive weekly hotel offers and supplies an email address for that purpose.

77.2 Not automatically within Section 7(a)

A pharmacy uses a receipt number for supplement promotions.

An employer shares salary data with lenders.

A hotel uploads former guests to advertising platforms.

A government uses beneficiary records for political messaging.

Marketing requires careful separation from the original transaction.

78. AI across Section 7

AI is not a Section 7 clause. The underlying processing must fit an actual legitimate use.

A lawful input source does not automatically make model training lawful.

A model generated under one clause must not be repurposed under another objective without reassessment.

79. Scraping and Section 7

Section 7(a) generally does not support scraping merely because information is accessible.

The person must have voluntarily provided the data to the Data Fiduciary for the specified purpose.

A public LinkedIn profile may be affected by Section 3(c)(ii). If the user genuinely made the data public, those fields may fall outside the Act.

But Section 7 becomes relevant for:

• non-public fields;

• leaked data;

• restricted profiles;

• generated inferences;

• recruiter notes;

• facial templates;

• combined risk scores.

A scraper cannot say:

“The person voluntarily provided the information to the internet, so Section 7(a) applies to us.”

The statutory words require provision to the Data Fiduciary for the specified purpose.

80. Vendors and processors

A processor acting on the instructions of a Data Fiduciary may process data within the Data Fiduciary’s authorised purpose.

Example

Examples:

• payroll vendor under Section 7(i);

• cloud provider supporting a public benefit under Section 7(b);

• CCTV maintenance vendor supporting Section 7(d);

• emergency communications provider under Section 7(h).

The vendor may become a separate Data Fiduciary if it decides to use the data for:

• advertising;

• commercial model training;

• benchmarking;

• product development;

• sale to other customers.

The original Section 7 ground does not travel automatically to the vendor’s independent purpose.

81. Retention under Section 7

A legitimate use does not create perpetual retention.

Retention should correspond to:

• duration of the specified request under Section 7(a);

• benefit administration under Section 7(b);

• statutory function under Section 7(c);

• disclosure obligation under Section 7(d);

• proceedings under Section 7(e);

• emergency duration under clauses (f) to (h);

• employment or liability purpose under Section 7(i).

Example

Examples:

• a broker should stop after the customer ends the search;

• disaster-location data should not become a permanent marketing database;

• emergency medical information should not be retained indefinitely for unrelated research;

• employee-security footage should follow a defined retention period;

• court records may be retained for the proceedings and applicable legal requirements.

82. Rights and Section 7

It is incorrect to state broadly that Data Principal rights disappear whenever processing relies on Section 7.

The exact wording of each right and any applicable exemption must be examined.

At a minimum:

• grievance redressal remains operationally important;

• accuracy matters where data is used for decisions or disclosure;

• security applies;

• retention must remain justified;

• applicable correction or erasure requests must be assessed under their statutory conditions.

A Data Fiduciary should not respond:

“We rely on legitimate use, so you have no rights.”

It should identify the specific provision governing the request.

83. Notice architecture for Section 7 processing

Although Section 5 directly addresses consent, a well-designed privacy statement should explain legitimate uses.

A practical structure is:

For emergency and police processing, notice may need to be delayed, limited or omitted where giving notice would frustrate the lawful purpose or create danger. That conclusion should follow from applicable law, not organisational convenience.

84. GDPR comparison

The GDPR’s six lawful bases are broader in architecture than Section 7. The EDPB states that organisations must identify a lawful basis before processing and that special-category information is subject to additional conditions.

GDPR principles should inform careful analysis of necessity and proportionality. They should not be copied as if they were enacted Indian requirements.

85. Operational interpretation

A Data Fiduciary relying on Section 7 should document:

1. the precise processing activity;

2. the exact clause;

3. the lawful purpose;

4. categories of personal data;

5. Data Principals affected;

6. recipients and processors;

7. why the processing fits the clause;

8. limits on use;

9. retention trigger;

10. security measures;

11. applicable transparency;

12. rights-handling procedure.

The record should not simply state:

“Legal basis: legitimate use.”

A proper entry would say:

“Section 7(i): processing employee name, employee number, access logs and repository activity to prevent unauthorised extraction of source code and protect the employer’s intellectual property.”

Or:

“Section 7(d): recording and retaining CCTV footage at the mandated entrance and parking area for the prescribed period under the applicable State public-safety law and making it available to the designated police authority where lawfully required.”

86. Final interpretation

Section 7 is not a broad exception to consent. It is the DPDPA’s closed catalogue of specific situations in which Parliament has judged that processing may proceed without Section 6 consent.

Clause (a) protects ordinary, person-initiated interactions, but only for the specific purpose for which data was voluntarily provided. It does not authorise hidden collection, general marketing, profiling or indefinite retention.

Clause (b) enables prescribed State benefits and services through previous public-service consent or notified State records. It does not create an unlimited intergovernmental data-sharing power.

Clause (c) permits State functions and processing connected with sovereignty, integrity and State security. It does not itself create police, surveillance or interception powers. Those powers must come from other law.

Clause (d) enables a person to satisfy a legal duty to disclose information to the State. It is narrower than a general legal-obligation ground and must follow the disclosure limits of the mandating law.

Clause (e) permits compliance with Indian judgments, decrees and orders and defined foreign civil or contractual decisions. Processing must remain connected with compliance.

Clause (f) is limited to genuine medical emergencies involving threats to life or immediate health. It cannot support routine health analytics.

Clause (g) permits treatment and health services during epidemics, outbreaks and public-health threats. It does not automatically authorise permanent commercial reuse of crisis data.

Clause (h) supports safety and assistance during disasters and breakdowns of public order. Its emergency character should determine the data, scale and duration.

Clause (i) is the operative foundation for core employment processing and protection of employers from loss or liability. It avoids fictitious employee consent but does not create an unrestricted surveillance or commercialisation power.

Across all clauses, three controlling ideas remain constant:

EXACT CLAUSE

The processing must fit the words of a particular paragraph.

EXACT PURPOSE

The data may be used only for the purpose that brings it within that paragraph.

CONTINUING COMPLIANCE

Security, accuracy, retention, processor accountability, rights and other DPDPA duties remain applicable.

The practical rule is:

Key point

A Data Fiduciary should never begin with the conclusion that an activity is legitimate. It should begin with the statutory words, identify the exact clause, prove the connection between the data and the permitted use, and prevent every later operation from exceeding that boundary.