Explaining Lawful Basis

Every privacy program needs a simple answer to a hard question:

Why are we allowed to process this personal data?

Under India's DPDP Act, the answer starts with lawful basis. A Data Fiduciary may process personal data only in accordance with the Act and for a lawful purpose. The Act recognises two broad grounds for processing:

1. consent given by the Data Principal; or
2. certain legitimate uses specified in the Act.

This is different from GDPR's wider lawful-basis model. DPDP does not use a six-basis structure like consent, contract, legal obligation, vital interests, public task, and legitimate interests. Instead, DPDP uses consent as the main operating model and then defines specific "certain legitimate uses" where processing can occur without fresh consent.

For Indian compliance, the practical task is to classify every processing activity into one of these DPDP grounds and keep evidence that the classification is correct.

What "lawful purpose" means

The DPDP Act states that personal data may be processed only for a lawful purpose. A lawful purpose is a purpose that is not expressly forbidden by law.

That sounds broad, but it is not a blank cheque.

A purpose may be lawful in the general sense and still fail DPDP compliance if:

• the Data Principal was not given a valid notice;
• consent was not validly obtained where consent is required;
• the data collected is not necessary for the specified purpose;
• the organisation relies on a legitimate-use category that does not actually apply;
• the processing continues after consent withdrawal without another valid basis;
• a child or person with disability is involved and verifiable consent rules apply;
• security safeguards are weak;
• retention continues beyond the required period; or
• the organisation cannot prove its basis during a Board inquiry.

Lawful purpose is the starting line. It is not the full compliance test.

The DPDP lawful-basis map

Processing ground	When it applies	What must be proved
Consent	The Data Principal gives valid consent for a specified purpose	Notice, consent action, purpose, personal data, timestamp, withdrawal route
Voluntary provision	The Data Principal voluntarily provides personal data for a specified purpose and has not indicated non-consent	Context, request, purpose, data provided, no objection
State benefit/service use	State or instrumentality processes data for prescribed subsidy, benefit, service, certificate, licence, or permit	Statutory basis, prescribed purpose, standards followed
State function/security	State function under law or in interests such as sovereignty, integrity, or security of the State	Legal authority and purpose
Legal disclosure obligation	Processing to disclose information to the State or its instrumentalities under law	Applicable law and disclosure requirement
Judgment/order compliance	Processing to comply with judgment, decree, or order	Order details and required data
Medical emergency	Response to threat to life or immediate health	Emergency context and necessity
Public health threat	Medical treatment or health services during epidemic, outbreak, or public health threat	Public health context and necessity
Disaster/public order	Safety, assistance, or services during disaster or public order breakdown	Event context and assistance purpose
Employment/safeguarding employer	Employment purposes or protecting employer from loss or liability	Employment relationship, risk, necessity, proportionality

The most common business grounds are consent, voluntary provision for a specified purpose, legal obligation, order compliance, and employment-related processing. Public-sector and emergency categories require careful legal review.

Consent: the primary DPDP operating model

Consent under DPDP must be:

• free;
• specific;
• informed;
• unconditional;
• unambiguous;
• based on clear affirmative action;
• tied to a specified purpose; and
• limited to personal data necessary for that purpose.

This means a consent checkbox alone is not enough. The full consent event must connect:

• who gave consent;
• what notice was shown;
• what personal data was covered;
• what purpose was stated;
• when and where consent was given;
• what action demonstrated consent;
• what language/version of the notice applied;
• whether a Consent Manager was involved;
• how withdrawal is available; and
• whether downstream processors received the correct instruction.

What makes consent invalid or weak

Consent may be invalid, partly invalid, or hard to defend if:

• it is bundled with unrelated purposes;
• it asks for more data than the purpose needs;
• it is hidden inside long terms;
• it uses pre-ticked boxes or passive acceptance;
• withdrawal is harder than giving consent;
• the Data Principal cannot understand the request;
• the notice does not explain the personal data and purpose;
• the organisation cannot prove what was shown;
• the consent attempts to waive statutory rights;
• the processing continues after withdrawal without another valid basis; or
• the consent was obtained from a child without verifiable parental consent.

The DPDP Act makes proof especially important. If consent is the basis of processing and the issue arises in a proceeding, the Data Fiduciary must be able to prove that notice was given and consent was obtained in accordance with the Act and Rules.

Notice is part of the lawful-basis evidence

Consent does not stand alone. It depends on notice.

A DPDP notice should explain:

• the personal data proposed to be processed;
• the specified purpose of processing;
• how the Data Principal may withdraw consent;
• how the Data Principal may exercise rights;
• how the Data Principal may complain to the Board;
• the contact details of the DPO or responsible person; and
• the available language/accessibility options required by the Act and Rules.

The DPDP Rules require notices to be understandable independently of other information and to use clear and plain language. They also require the notice to include a website/app link or other means through which the Data Principal can withdraw consent, exercise rights, and complain to the Board.

For audit purposes, store every notice version as a record, not just as website content.

Consent withdrawal

Where consent is the basis of processing, the Data Principal has the right to withdraw consent at any time. The ease of withdrawal should be comparable to the ease of giving consent.

After withdrawal, the Data Fiduciary must stop processing and cause its Data Processors to stop processing the relevant personal data unless continued processing is required or authorised under the Act, Rules, or another law.

Withdrawal does not make past consent-based processing unlawful. It changes what may happen after withdrawal.

Withdrawal workflow

Step	Action
Identify consent	Match the withdrawal to the consent receipt and purpose
Validate requester	Confirm Data Principal or authorised Consent Manager
Stop processing	Disable purpose-specific processing in active systems
Notify processors	Send processor stop/erase instructions where needed
Assess retention	Decide if legal retention applies
Trigger erasure	Erase where retention is not required
Confirm outcome	Notify the Data Principal
Preserve proof	Store withdrawal receipt and downstream action logs

Consent Managers

The DPDP Act recognises Consent Managers as registered entities that act as a single point of contact for Data Principals to give, manage, review, and withdraw consent through an accessible, transparent, and interoperable platform.

For Data Fiduciaries, this creates two design obligations:

• accept and process consent instructions through approved Consent Manager flows; and
• preserve evidence that a Consent Manager instruction was received, verified, and acted upon.

Consent Manager integration should not be treated as a generic API endpoint. It affects the legal basis for processing and must update the consent ledger, purpose map, and downstream processor instructions.

Certain legitimate uses: not the same as GDPR legitimate interests

DPDP's "certain legitimate uses" should not be confused with GDPR's "legitimate interests."

GDPR legitimate interests involves a balancing test between the controller's interest and the individual's rights and freedoms. DPDP certain legitimate uses are specific categories listed in the Act.

The practical difference:

• GDPR legitimate interests is an evaluative basis.
• DPDP certain legitimate uses are statutory categories.

Under DPDP, a Data Fiduciary should not say "we have a legitimate interest" and assume processing is allowed. It must identify the specific legitimate-use category under the Act and document why it applies.

Legitimate use 1: voluntary provision for a specified purpose

This is the legitimate-use category most private organisations will encounter.

It applies when a Data Principal voluntarily provides personal data for a specified purpose and has not indicated that they do not consent to that use.

Examples:

• a customer gives a mobile number to receive a purchase receipt;
• a person emails a broker asking for rental options and shares contact details;
• a website visitor submits a support request with an email address;
• an event attendee shares a business card for follow-up about that event; or
• a user submits a service request that cannot be fulfilled without the provided data.

Controls

To rely on this basis, document:

• what the Data Principal requested;
• what data was voluntarily provided;
• what specified purpose was apparent;
• why the data was necessary for that purpose;
• whether the Data Principal later objected or indicated non-consent;
• when processing stopped after the purpose ended; and
• whether any further use requires consent.

Boundary

Voluntary provision for one purpose does not authorise unrelated reuse.

If a customer gives a phone number to receive a receipt, that does not automatically authorise promotional calls. If a person asks for a rental listing, that does not automatically authorise unrelated marketing or profiling.

Legitimate use 2: State benefits, services, certificates, licences, and permits

The Act allows the State and its instrumentalities to process personal data for prescribed subsidies, benefits, services, certificates, licences, or permits where statutory conditions are met.

This category is mainly relevant to public-sector systems, government service delivery, and vendors supporting government programs.

Controls

Teams should document:

• the government function or service;
• the applicable prescription or legal authority;
• the category of Data Principals affected;
• the databases or records used;
• the standards followed for processing;
• security and access controls;
• retention rules; and
• processor/vendor responsibilities.

Private vendors supporting such processing should not independently expand the purpose beyond the government-authorised scope.

Legitimate use 3: State functions, sovereignty, integrity, and security

The Act allows processing for performance by the State or its instrumentalities of functions under law and for specified public interests such as sovereignty, integrity of India, or security of the State.

This is not an ordinary private-sector business basis.

Where a private company receives a request connected to this category, it should route the matter through legal review and preserve:

• the requesting authority;
• the legal basis cited;
• the scope of requested data;
• the response decision;
• data disclosed;
• date and method of disclosure; and
• internal approvals.

Legitimate use 4: legal disclosure obligations

Processing may be allowed where a person must disclose information to the State or its instrumentalities under applicable law.

Examples may include statutory reporting, regulatory filings, lawful information requests, or sectoral compliance obligations.

Controls

Document:

• the law requiring disclosure;
• the authority receiving it;
• the minimum data required;
• the legal deadline;
• approval trail;
• transmission method;
• disclosure log; and
• retention period.

The key rule is data minimisation. A legal obligation to disclose some information is not permission to disclose everything.

Legitimate use 5: judgments, decrees, and orders

Processing may be allowed to comply with a judgment, decree, or order issued under law in India, or certain foreign judgments or orders relating to contractual or civil claims.

This basis may apply to:

• court orders;
• tribunal directions;
• arbitral or civil claim orders;
• litigation discovery;
• enforcement actions; or
• legally binding settlement-related processing.

Controls

Preserve:

• copy or reference of the order;
• jurisdiction and authority;
• required action;
• data scope;
• internal legal review;
• disclosure recipient;
• transfer method; and
• evidence of compliance.

Legitimate use 6: medical emergency

Processing may be allowed to respond to a medical emergency involving a threat to life or immediate threat to health of the Data Principal or another individual.

This category is narrow and context-specific.

Examples:

• emergency hospital admission;
• ambulance coordination;
• urgent health information exchange;
• emergency contact notification; or
• life-threatening incident response.

Controls

Document:

• emergency nature;
• individual affected;
• personal data used;
• recipient or responder;
• time sensitivity;
• decision-maker; and
• when emergency processing ended.

Do not reuse emergency data later for unrelated analytics, marketing, or profiling without another valid basis.

Legitimate use 7: epidemic, outbreak, and public health threat

Processing may be allowed for medical treatment or health services during an epidemic, disease outbreak, or other threat to public health.

This may apply to healthcare providers, public health authorities, government programs, employers in limited contexts, and service providers supporting public health measures.

Controls

Document:

• public health context;
• source of authority or guidance;
• affected population;
• data fields processed;
• recipients;
• retention limits;
• access controls; and
• post-event deletion or anonymisation plan.

Legitimate use 8: disaster or public order breakdown

Processing may be allowed to ensure safety or provide assistance or services during a disaster or breakdown of public order.

Examples:

• evacuation assistance;
• emergency shelter coordination;
• disaster relief distribution;
• missing-person support;
• emergency communications; or
• continuity services during civil disruption.

Controls

Document:

• event type;
• assistance purpose;
• data collected;
• agencies or partners involved;
• time period;
• retention limit; and
• closure review once normal conditions resume.

Legitimate use 9: employment and employer protection

The Act recognises processing for employment purposes and for purposes related to safeguarding the employer from loss or liability. Examples include prevention of corporate espionage, maintenance of confidentiality of trade secrets, intellectual property, classified information, or provision of a service or benefit sought by an employee.

This is important for HR, security, IT, finance, and workplace operations.

Examples

• payroll processing;
• benefits administration;
• access control;
• employee helpdesk support;
• investigation of data leakage;
• protection of trade secrets;
• device and network security monitoring;
• compliance training records;
• travel and expense processing; and
• workplace safety processes.

Controls

Employment-related processing should still be:

• purpose-specific;
• proportionate;
• access-controlled;
• communicated through employee privacy notices;
• retained only as needed;
• separated from unrelated uses;
• auditable; and
• reviewed for high-risk monitoring.

Employee monitoring deserves special attention. Even if a safeguard basis exists, broad or hidden surveillance may create legal, employee-relations, and proportionality risks.

Consent or legitimate use: decision tree

Use this decision tree before launching a processing activity.

Question	If yes	If no
Is the purpose expressly forbidden by law?	Do not process	Continue
Is the purpose covered by a specific legitimate-use category?	Document category and controls	Consider consent
Did the Data Principal voluntarily provide data for this specific purpose?	Use voluntary-provision analysis	Continue
Is this employment or employer-protection processing?	Use employment basis with safeguards	Continue
Is this required by law, order, emergency, State function, or disaster response?	Route through legal review and document	Continue
Is consent practical, free, specific, informed, and revocable?	Build consent notice and ledger	Reassess purpose
Is the data necessary for the specified purpose?	Limit collection accordingly	Reduce data or do not collect
Can withdrawal be honoured?	Implement withdrawal and processor stop flow	Reassess basis and design

Examples by business function

Function	Processing activity	Likely DPDP basis	Notes
Marketing	Newsletter signup	Consent	Keep consent receipt and unsubscribe/withdrawal flow
Sales	Responding to demo request	Voluntary provision or consent depending on form design	Do not reuse for unrelated campaigns without consent
Product	Account creation	Consent or voluntary provision depending on journey	Notice must describe data and purpose
Support	Resolving ticket submitted by user	Voluntary provision	Use only for support purpose unless consent exists for more
Billing	Invoice generation	Consent, legal obligation, or contract-linked purpose under broader law analysis	Retain statutory records where required
HR	Payroll	Employment purpose	Employee notice and access controls needed
Security	Device access logs	Employer protection/security safeguard	Define scope and retention
Compliance	Regulatory disclosure	Legal disclosure obligation	Minimise and log disclosure
Healthcare	Emergency treatment	Medical emergency	End emergency processing after need ends
Government vendor	Benefit eligibility processing	State benefit/service basis	Vendor must stay within authorised scope

Lawful basis register

Every organisation should maintain a lawful basis register. It should be linked to the data inventory, consent ledger, notice repository, retention schedule, and processor register.

Recommended fields:

Field	Purpose
Processing activity	What the organisation does
System owner	Accountable team
Data Principal category	Customer, employee, vendor, child, beneficiary
Personal data fields	Data processed
Specified purpose	DPDP purpose statement
DPDP basis	Consent or specific legitimate use
Notice version	Evidence of transparency
Consent receipt ID	Required where consent applies
Withdrawal path	Required where consent applies
Processor list	Downstream processing
Retention rule	Erasure and legal retention
Risk flags	Child data, sensitive context, SDF relevance, public-sector, emergency
Reviewer	Legal/privacy approval
Last review date	Freshness of classification

How to audit lawful basis

Audit teams should test lawful basis by asking:

• Is every processing activity mapped to consent or a specific legitimate use?
• Is the specified purpose clear enough for a Data Principal to understand?
• Is the data collected necessary for that purpose?
• Does the notice match the actual processing?
• Is consent stored with notice version and timestamp?
• Can the organisation prove consent if challenged?
• Can withdrawal be performed with comparable ease?
• Are processors instructed to stop after withdrawal?
• Are legitimate-use claims tied to a statutory category?
• Is retention justified after purpose completion?
• Are children and persons with disabilities handled through correct consent rules?
• Are employment monitoring activities proportionate and documented?

If the answer is unclear, the lawful basis is not operationally ready.

Common mistakes

Mistake 1: Calling every basis "consent"

Some processing is better classified as a legitimate use or legal requirement. Treating everything as consent can create withdrawal problems because the organisation may later need to keep processing data for billing, security, legal, or employment reasons.

Mistake 2: Calling every business need a legitimate use

DPDP legitimate uses are specific statutory categories. A commercial interest alone is not enough.

Mistake 3: Bundling multiple purposes into one consent

Account creation, service delivery, marketing, analytics, and partner sharing may require separate purpose treatment. One broad consent line is weak evidence.

Mistake 4: Forgetting processors

If consent is withdrawn, the Data Fiduciary must cause processors to stop processing unless another legal basis applies. The withdrawal workflow must reach processors.

Mistake 5: Not linking notice to consent

A consent record without the notice version is incomplete. The organisation must prove what the Data Principal saw.

Mistake 6: Confusing DPDP legitimate use with GDPR legitimate interest

The names sound similar, but they are legally different. A GDPR legitimate-interest assessment does not automatically satisfy DPDP's specific legitimate-use categories.

Implementation checklist

Use this checklist before go-live:

• Every processing activity has a DPDP basis.
• Each consent purpose has a notice version.
• Consent is captured through clear affirmative action.
• Consent is limited to necessary personal data.
• Withdrawal is as easy as consent.
• Withdrawal stops relevant processor activity.
• Legitimate-use processing is mapped to a statutory category.
• Employment processing is documented and proportionate.
• Legal disclosure processing has approval and disclosure logs.
• Emergency processing has event-based retention.
• Children's processing uses verifiable parental consent.
• DPO or responsible contact details are published.
• Retention and erasure are linked to purpose completion and withdrawal.
• Audit reports can export basis, notice, consent, processor, and retention evidence.

Where Vishwaas AI Fits

Vishwaas AI helps privacy, legal, security, and product teams maintain lawful-basis discipline under DPDP.

The platform should support:

• processing activity inventory;
• DPDP basis classification;
• consent and notice versioning;
• purpose-based consent receipts;
• withdrawal orchestration;
• processor stop instructions;
• legitimate-use documentation;
• retention and erasure controls;
• DPO/contact response records; and
• audit-ready lawful-basis reporting.

The goal is to move lawful basis out of spreadsheets and into the systems that actually collect, process, share, retain, and erase personal data.

Sources

• Ministry of Electronics and Information Technology: Digital Personal Data Protection Act, 2023
• Ministry of Electronics and Information Technology: Digital Personal Data Protection Rules, 2025