Processing under the legitimate uses

Section 7 of the Digital Personal Data Protection Act, 2023 sets out situations in which a Data Fiduciary may process personal data without consent. The Act calls them "certain legitimate uses".

The list is closed, and it is narrow. That combination matters more than either feature alone, because teams arriving from the European General Data Protection Regulation expect something the Act does not contain. There is no ground equivalent to "legitimate interests", under which a company names an interest of its own, tests whether the processing is necessary, and weighs that interest against the rights of the individual. The Act names specific situations. Processing either falls inside one of them or it needs consent.

The grounds a business will meet are employment, voluntarily provided data, court orders and duties to disclose, and the emergency and public interest grounds. Each permits specific processing and has a defined edge, and a ground read too widely protects nobody.

Removing the consent requirement removes one duty and leaves the rest in place, including purpose limitation, erasure once the purpose is served, security safeguards and breach intimation. Every organisation also needs a record that sets a ground against each purpose. This is not legal advice; take advice on your own facts before relying on any ground.

Why the Act has no general alternative

A closed list with no balancing test

Section 7 lists the situations in which processing may go ahead without consent, and the list is closed. An organisation cannot add to it by argument, however reasonable the argument. Understanding this prevents a category of error that turns up regularly in Indian compliance work.

Under the European regulation, a controller relying on legitimate interests carries out an assessment. It identifies the interest, considers whether the processing is necessary to serve it, and balances the interest against the rights and freedoms of the person. Where the balance favours the controller, the processing is lawful without consent. That flexibility makes it useful across a wide range of ordinary business activity.

Nothing of that shape appears in the DPDP Act. Its grounds are categorical: processing either matches a described situation or it does not, and no weighing exercise moves a situation from outside the list to inside it. A team that wrote a legitimate interests assessment for a European product, and files it as the basis for the same processing in India, has documented a test the Act does not recognise. The practical consequence is that a great deal of ordinary commercial processing in India needs consent: marketing, analytics, profiling, advertising, and the reuse of data for purposes unrelated to the original one.

For completeness, section 7 also contains grounds aimed mainly at the State and its instrumentalities, such as providing subsidies, benefits, services, certificates and licences, and performing functions under law or in the interest of the sovereignty, integrity and security of India. A private business will rarely rely on these.

Reading a ground carefully

Because the grounds are narrow, there is a temptation to read one widely enough to cover processing you would like to continue. That reading is the most expensive mistake available in this part of the Act. A ground stretched past its terms gives no protection, and it leaves a written record showing you considered the question and answered it wrongly. An organisation processing without consent on a ground that does not apply is processing without a basis.

A simple discipline helps. Before relying on any legitimate use, ask three questions in order:

• Does the processing match the situation the ground describes, in the Act's own words? A paraphrase is where the stretching happens.
• Is the processing necessary for that situation, or only convenient alongside it?
• Would you be comfortable explaining this ground to the person concerned, and to the Data Protection Board?

If any answer is shaky, consent is usually the safer route. Collecting it costs less than defending a ground that does not hold.

Each ground has a marked edge, and a team that reads only what a ground permits will over-apply it.

The grounds a business will use

Employment

For most private organisations, employment does the heaviest lifting. Section 7 allows processing for the purposes of employment, and for purposes related to safeguarding the employer from loss or liability. The Act gives examples: preventing corporate espionage, keeping trade secrets, intellectual property and classified information confidential, and providing any service or benefit sought by an employee. Payroll, attendance, performance reviews, workplace safety, and the group health cover an employee has enrolled in all sit comfortably inside it.

The value of this ground is that it removes an awkward problem. Consent from an employee is hard to treat as freely given, because the employee depends on the employer asking for it. A framework requiring employee consent for routine HR processing would rest that processing on weak footing. The Act avoids the difficulty by giving employment its own ground. A software services firm in Bengaluru is better off recording payroll under the employment ground than collecting joining-day consent forms it would later have to defend.

Two limits mark the edge of this ground. First, the processing has to relate to the employment or to protecting the employer from loss or liability. Promoting a director's unrelated side business to staff using their personal phone numbers falls outside it. Second, the ground covers the employment relationship alone, and an employer often holds data outside it. Data about a job applicant who was never hired, or about a former employee kept long after any purpose has ended, needs its own analysis.

Monitoring deserves particular care, because whether it fits depends on what is actually being protected. Watching for customer data being copied to personal drives can protect against a real loss. Tracking an employee's personal social media activity is very hard to justify in the same way. If a monitoring tool collects more than the protective purpose needs, the excess has no ground under it.

Data the person provided voluntarily

Section 7 allows processing for a specified purpose for which a Data Principal has voluntarily provided their personal data, where they have not indicated that they do not consent to its use. The ground fits situations where a person hands over information in order to receive something, and a separate consent transaction would add ceremony without adding protection. A customer of a D2C brand who sends a delivery address on WhatsApp so that an order can reach them has provided it voluntarily for that delivery. A shopper who gives a mobile number at a pharmacy counter so that a receipt can be sent has done the same.

The limits are strict, and they follow from the words:

• The purpose is fixed by what the data was provided for. The delivery address is available for the delivery, the return and the invoice. It is not available for a festive season campaign.
• The provision has to be voluntary. Information extracted as a condition of a service the person had no real way around is a different matter.
• An objection ends the reliance. You need a route through which a person can object, and a system that acts on the objection when it arrives.

This ground is easier to misapply than any other, because almost all customer data was "provided by the customer" in some sense. The question it asks is narrower: does the specific processing you now have in mind match the purpose for which the data was given at the time? If you rely on this ground, record the purpose for which each kind of data was provided. This is the same purpose register that consent work relies on. Each new use is then tested against the record, and nobody assumes it is covered by the original provision.

Court orders and duties to disclose

Two related grounds deal with legal compulsion. One permits processing to comply with any judgment, decree or order issued under Indian law, and with certain foreign judgments and orders on contractual or civil claims. The other permits processing to fulfil an obligation under Indian law to disclose information to the State or its instrumentalities, in line with what that law says about disclosure. Producing documents under a court order, or filing information a statute requires you to give to a government authority, does not need consent.

The edge here is that the order or the obligation has to exist. A practice your team considers prudent, a norm in your industry, or a clause in a contract with a business partner is not an obligation under law, and processing justified by any of those needs a different ground. Organisations in regulated sectors should map their regulatory reporting duties explicitly, because these are the cases where this ground does the work. An NBFC reporting to a credit information company, or a broker filing with a market regulator, should be able to point to the specific provision behind each flow.

Note what these two grounds do not say. The Act has no general ground for "compliance with any legal obligation" of the kind found in the European regulation. Keeping records because a law requires it is handled elsewhere: section 8 requires you to erase personal data once the purpose is served, unless retention is necessary for compliance with any law. So an NBFC keeping loan records for the period that tax and sector rules require is on solid footing, through that retention clause.

Retention is where this causes the most confusion in practice. A statutory retention period runs alongside the DPDP Act, and the retention rule for those records follows the longer statutory period. Trouble starts when a single retention rule is applied to a data set that mixes statutory records with data that has no such requirement. Either you destroy records you were obliged to keep, or you hold the rest long after its purpose has ended. Splitting the two in your retention schedule fixes both problems. Note also that Rule 6 asks you to keep logs and related data for at least one year, which sits beside any sectoral period.

The emergency and public interest grounds

Medical emergencies and public health

Section 7 permits processing to respond to a medical emergency involving a threat to the life of, or an immediate threat to the health of, the Data Principal or any other individual. A hospital in Nagpur receiving an unconscious patient from a road accident can look up records held elsewhere without stopping for a consent transaction. The ground exists because the alternative would cause harm. A related ground covers measures to provide medical treatment or health services to any individual during an epidemic, an outbreak of disease or any other threat to public health.

Both grounds are tied to the situation they describe, and neither creates a general permission for health data. Routine patient engagement, appointment reminders that promote a new wellness package, marketing lists built from patient records, and commercial analytics on clinical data are ordinary processing that needs an ordinary basis, which usually means consent. The emergency ground needs an emergency: something real and time bound. A label attached to a category of work does not qualify.

For hospitals and diagnostic chains, the practical implication is that one system will hold data processed on several different grounds at once. The emergency access path runs on this ground. The ongoing treatment relationship rests on the patient's consent. A newsletter list needs its own consent. Retention differs across all three. Recording which ground applied to which processing event is what lets you answer a question about a particular record months later.

Disasters and breakdowns of public order

A further ground permits processing to ensure the safety of, or to provide assistance or services to, any individual during a disaster or a breakdown of public order. Think of a telecom operator sharing location data with relief teams during a cyclone on the Odisha coast, or a logistics company tracking stranded drivers during floods in Assam. The situations are unpredictable, and the processing is bounded by the situation, which gives this ground a feature you should build for deliberately.

That feature is a time limit on reliance. Processing is permitted for as long as the disaster and the measures responding to it continue. Once the situation ends, continued use of the data collected during it needs a fresh ground, and data no longer needed for the response falls under the ordinary erasure duty. An emergency data feed set up during a crisis and left running afterwards is processing on a ground that has lapsed.

This suggests a specific practice for any organisation likely to use this ground, whether in logistics, utilities, telecom, healthcare or public-facing services. Treat emergency processing as a defined mode, with a recorded start, a named person accountable for it, and a review that formally closes it. Setting that up in advance costs a short written procedure. Doing it afterwards means reconstructing what was processed, and on what footing, after the people involved have moved on.

What does not change

The duties that apply whatever the ground

A legitimate use removes the need for consent and removes nothing else. This matters for anyone planning the work, because a common misreading treats section 7 as an exemption from the Act. Processing on any ground still carries the other duties of a Data Fiduciary:

• Purpose limitation. The data is used for the purpose relied on, and no further.
• Erasure when the purpose is served. The data goes once the purpose is served, unless a law requires it to be kept, and processors have to be made to erase it too.
• Reasonable security safeguards. Failing these can draw a penalty of up to 250 crore rupees, the highest in the Schedule.
• Breach intimation. A breach must be intimated to the Board and to affected people without delay, with a detailed report to the Board within 72 hours, whatever the ground the data was processed on.
• Grievance redressal. People need a working route to raise a complaint, answered within at most 90 days.
• Processor contracts. Anyone processing on your behalf must be engaged under a valid contract.

Your records of processing also have to describe legitimate use processing alongside consent-based processing, because they describe what the organisation does.

Do not draw the boundary of your compliance programme around consent. A programme built to handle consent well, with legitimate use processing treated as out of scope, will leave retention, security and breach duties unaddressed for a large share of what you hold. Employee data alone is often one of the largest personal data holdings in a mid-sized company, and it rests almost entirely on a legitimate use. Leaving it out of scope leaves out a considerable part of the organisation's exposure.

Rights and notice

The rights of Data Principals interact with the ground in ways worth setting out carefully, because this is a place where many internal policies, and some commentary, get it wrong.

Under sections 11 and 12, the rights to access a summary of personal data, and to have it corrected, completed, updated or erased, are framed around data the person consented to, including data they voluntarily provided under the first legitimate use. They do not, on their wording, extend to processing on the other legitimate uses, such as employment or a court order. The right to grievance redressal and the right to nominate someone apply more broadly. Many employers will still choose to answer an employee's question about what HR holds, and doing so is good practice. Know, though, which answers the law requires and which you give by choice, and make sure your request-handling process can tell the two apart.

Erasure works differently across grounds, and this is where teams slip. Withdrawal of consent leads to erasure of the data held for the withdrawn purpose, unless a law requires it to be kept. Where processing rests on a legitimate use, there is no consent to withdraw, so erasure follows the purpose and the retention period. A person cannot end processing on the employment ground by withdrawing something they never gave. You should be able to explain that clearly, because an employee who asks for their HR records to be erased and receives a refusal deserves a reason they can understand.

Notice is easy to get wrong in the other direction. The detailed notice duty in section 5 and Rule 3 accompanies a request for consent, and processing on a legitimate use involves no such request. Transparency still has value, and people often expect it. So describe legitimate use processing in your general privacy information, even where a consent notice is not required. An employee handbook that explains what the employer processes and why is good practice, and it answers questions that would otherwise arrive as grievances.

Recording the ground for each purpose

A ground for each purpose

Everything above leads to one requirement: a record connecting each purpose to the ground relied on for it. A general statement that the organisation "relies on consent where required and on legitimate uses where available" describes an approach and gives no position anyone can test. The record needs an entry for each purpose naming the ground, and for a legitimate use, naming which clause of section 7.

This level of detail matters because a single data set commonly supports several purposes on different grounds. Employee personal data supports payroll on the employment ground, disclosures a tax law requires on the disclosure ground, an emergency contact process on the medical emergency ground, and an invitation to an optional company cricket tournament that needs consent. Recording one ground for the whole data set answers none of these correctly. Recording a ground for each purpose gives a position you can defend and, more usefully, one your own engineers can build to, because retention and access rules follow the purpose, whichever table holds the data.

This record is the purpose register used for consent, with a column added for the ground. If you built it for the consent work, you already have most of it. If you have not, questions about grounds cannot be answered at all, because there is no list of purposes to answer them against.

What each entry should contain

For each purpose, the record should note:

• the purpose in plain words, as it would appear in a notice;
• the categories of personal data used for it;
• the ground relied on, and for a legitimate use, the clause of section 7;
• why the ground applies, in a sentence or two, because the reasoning fades and the person who did it moves on;
• the retention period and what determines it, including any statutory period;
• the systems that perform the processing, and any processors involved;
• who approved the decision, and when it was last reviewed.

Two habits keep the record accurate. Review it whenever the organisation changes what it does, through the same release checkpoint that keeps notices and data flows current, because a new purpose introduced without an entry is processing without a recorded ground. And test it now and then by picking a purpose and following it into the systems, to confirm that the processing described is the processing taking place. A register that has drifted from the systems is a document, and it stops working as a control.

The register also settles a question that comes up repeatedly: what to do when a purpose could rest on either consent or a legitimate use. Choose one, record it, and build accordingly, because the two lead to different behaviour. Processing on consent has to stop on withdrawal; processing on a legitimate use does not. A system built for one and documented as the other will behave wrongly in exactly the situation a regulator looks at. Making the choice when the purpose is recorded prevents that. When marketing later proposes a new use for delivery data, the record shows quickly that the original ground does not stretch that far.

Bringing the series together

The three articles in sequence

The Act rests on consent more heavily than comparable laws do. Consent arriving through the registered Consent Manager framework, which commences around November 2026, requires a Data Fiduciary to build five things: a purpose register, an authoritative consent store, processing systems that consult it as they act, reliable identity matching, and a written mapping between an intermediary's purposes and your own.

For children under 18, the work covers establishing age, which no method settles completely; verifying a parent, with Rule 10 pointing towards government-backed credentials; the prohibitions on tracking, behavioural monitoring and targeted advertising, which consent cannot cure; and the Fourth Schedule exemptions, which should be documented against their conditions before anyone relies on them.

The legitimate uses mark the boundary: a closed, narrow list of grounds with no balancing test, the duties that continue whatever the ground, and a record connecting each purpose to its ground, which is where all of this work leads.

What the series points to

Each of these duties comes down to the same small set of underlying capabilities:

• knowing what purposes you process personal data for;
• knowing which ground supports each one;
• holding a record of consent, with its lifecycle, where consent is the ground;
• being able to identify a person across your systems;
• having processing systems that consult that state as they act;
• keeping evidence of what the systems did.

An organisation with those capabilities can meet the Consent Manager framework, the children's duties and the legitimate use record keeping without treating each as a separate programme.

That is the practical reason to build in this order, capability by capability, and to avoid working obligation by obligation. The purpose register serves the consent work, the children's work and the record of grounds. One consent store serves both the intermediary interface and the parental consent flow. The architecture that checks state as processing happens serves consent withdrawal and the ban on monitoring children. Build the capabilities once and most of the clauses are already answered, which is the position worth reaching before most duties apply around 13 May 2027, as notified, unless amended.

Summary

Section 7 permits processing without consent in a closed and narrow set of situations, and the Act contains no general ground resting on a balancing exercise of the European kind. For a private business, employment carries most of the weight, covering employment purposes and the protection of the employer from loss or liability, and it removes the awkwardness of relying on consent from someone who depends on you. Data voluntarily provided for a specified purpose is available for that purpose only. The legal grounds cover court orders and duties to disclose to the State, while retention a law requires is handled through the erasure provision in section 8. The emergency, public health and disaster grounds are tied to their situations, and reliance on them is time bound.

A legitimate use removes the consent requirement and nothing else, so purpose limitation, erasure, security safeguards, breach intimation, grievance handling, processor contracts and the record of processing all continue to apply. The rights to access, correction and erasure are framed around consent and voluntarily provided data, while grievance redressal and nomination apply more broadly, and erasure on a legitimate use follows the purpose because there is no consent to withdraw. What all of this needs is a record connecting each purpose to its ground, with the clause named, the retention rule stated and the systems identified, reviewed when the organisation changes and tested against the systems from time to time.

TrustOS holds that purpose register with a ground against each purpose, links it to notices, retention rules and the systems involved, and keeps the review history as evidence. Choosing the ground for each purpose remains a judgement your teams make, with advice where the answer is unclear, and Code Colonies consulting can help build both the record and the system changes that make it true. For a shorter reference, see the guide to legitimate uses, and for consent arriving from outside, see preparing for registered Consent Managers.