Section 8 - General obligations of Data Fiduciary

Key point

Detailed clause-by-clause commentary on accountability, processor governance, data quality, compliance measures, security, breach notification, retention, contact information and grievance redressal

Section 8 is the operational centre of the DPDPA. Sections 4 to 7 identify when personal data may be processed, while Section 8 determines how a Data Fiduciary must govern that processing throughout its lifecycle, including where vendors, cloud providers, payroll companies, recruitment agencies, CCTV operators, marketing firms and AI providers are involved.

The practical significance of Section 8 is that a lawful ground is only the beginning. Consent or a legitimate use does not cure inaccurate data, an invalid processor arrangement, weak security, delayed breach escalation, indefinite retention or an ineffective grievance channel.

1.1 (1): Accountability of the Data Fiduciary

A Data Fiduciary shall, irrespective of any agreement to the contrary or failure of a Data Principal to carry out the duties provided under this Act, be responsible for complying with the provisions of this Act and the rules made thereunder in respect of any processing undertaken by it or on its behalf by a Data Processor.

2. “A Data Fiduciary shall”

A Data Fiduciary is the person who determines, alone or together with another person, the purpose and means of processing personal data.

In plain language, the Data Fiduciary decides:

• why personal data will be processed;

• what personal data will be used;

• whose personal data will be used;

• what essential operations will be performed;

• which persons will receive access;

• which vendors will be involved;

• how long the data will be retained;

• what consequences or decisions may follow.

The word “shall” creates a mandatory obligation. Compliance is not optional, dependent on contractual negotiation or subject to the Data Fiduciary’s commercial convenience.

3. Roles must be determined before drafting the contract

The correct starting point is not a standard form of data-processing agreement. It is the transaction itself.

Before inserting any data protection clause, the parties must answer:

1. Does the transaction involve personal data?

2. If it does, what personal data is involved?

3. Whose personal data is involved?

4. Why will each party process it?

5. Which party determines the purpose and essential means?

6. Is the recipient a Data Processor, a separate Data Fiduciary or a participant in joint determination?

The attached practice note correctly identifies failure to conduct this preliminary assessment as one of the most common drafting errors. A data protection clause should not be inserted mechanically into every services contract. The clause must reflect the actual processing arrangement.

3.1 Example: Air-conditioning contractor

An air-conditioning contractor enters the premises, services HVAC systems and leaves. If it does not access visitor registers, employee systems, access-control records or other personal data, the commercial arrangement may not require processor provisions merely because technicians enter the premises.

3.2 Example: CCTV maintenance provider

A CCTV contractor installs cameras and has remote access to recordings of customers, staff and visitors. Personal data is plainly involved. The contract must address authorised access, security, breach escalation, retention, export of footage, deletion and termination.

3.3 Example: Furniture supplier

A supplier delivers tables and chairs based on an aggregate order. Ordinarily, no personal data is processed.

If the supplier also receives employee names, departments and measurements to produce personalised workstations or nameplates, a limited personal-data flow now exists and must be governed accordingly.

3.4 Example: Security agency

A security agency may appear to provide only guards. In practice, its personnel may:

• maintain visitor registers;

• inspect identification;

• record vehicle numbers;

• collect contractor details;

• operate access-control systems;

• view CCTV footage.

The processing function, not the commercial label “guarding services,” determines whether data protection provisions are required. This is one of the practical distinctions highlighted in the attached practice note.

4. Contractual labels do not determine the role

A party is not a Data Processor merely because the contract calls it one.

The role must be determined processing operation by processing operation.

The EDPB’s guidance treats controller and processor as factual and functional concepts. The controller decides the purposes and essential means; the processor acts on the controller’s behalf. A processor that moves beyond instructions and begins determining its own purpose becomes a controller for that operation. The controller does not need physical access to the data to be responsible. These principles are highly persuasive when distinguishing Data Fiduciaries and Data Processors under the DPDPA.

5. Three common relationship structures

The DPDPA definition of Data Fiduciary expressly recognises that purpose and means may be determined alone or in conjunction with others. The Act does not provide a detailed allocation mechanism equivalent to GDPR Article 26. Parties jointly determining processing should therefore document responsibilities carefully.

A contract cannot turn a genuine separate Data Fiduciary into a processor by requiring it to accept that label.

6. Fiduciary-to-processor relationship

A payroll company that calculates salaries using the employer’s records and instructions is ordinarily a processor.

The employer decides:

• which employees are paid;

• salary amounts;

• deductions;

• payment dates;

• the data required;

• the retention purpose.

The payroll company may decide technical implementation details, but it does not independently decide to use salary information for commercial purposes.

If the payroll company uses salary and banking information to offer personal loans, it adopts an independent purpose. For that operation, it is no longer acting merely on behalf of the employer.

7. Fiduciary-to-fiduciary relationship

An employer shares necessary employee information with an insurer to enrol employees in a group policy.

The insurer may independently determine:

• underwriting;

• policy administration;

• claims decisions;

• legal retention;

• fraud investigation.

The insurer may therefore be a separate Data Fiduciary for those operations.

A clause requiring the insurer to process every item only on the employer’s instructions may not reflect reality. Instead, the agreement should identify the point at which the insurer begins independent processing and allocate responsibilities appropriately.

8. Joint determination

Two hotel companies jointly design a shared loyalty programme. They decide:

• eligibility;

• data fields;

• rewards;

• profiling;

• communications;

• retention.

Their decisions may be common or sufficiently convergent to make them joint participants in determining the processing.

A contractual arrangement should identify:

• which entity gives notice;

• which entity obtains consent;

• which entity responds to requests;

• how corrections propagate;

• who coordinates a breach;

• who communicates with the Board;

• how processors are approved;

• who carries out erasure;

• how liability is allocated internally.

Internal allocation does not remove statutory responsibilities toward Data Principals or the Board.

9. “Irrespective of any agreement to the contrary”

Section 8(1) makes accountability non-transferable.

A contract may allocate tasks and financial risk. It cannot remove the Data Fiduciary’s responsibility under the DPDPA.

A clause stating:

“The vendor alone shall be responsible for all compliance with the DPDPA, and the customer shall bear no responsibility for processing undertaken through the services”

cannot defeat Section 8(1).

The Data Fiduciary may still obtain:

• indemnity;

• reimbursement;

• audit rights;

• insurance;

• contractual remedies;

• termination rights.

Those rights operate between the contracting parties. They do not prevent the Board from holding the Data Fiduciary responsible.

10. “Failure of a Data Principal to carry out duties”

A Data Principal’s wrongdoing does not cancel the Data Fiduciary’s duties.

10.1 False information

An applicant submits a forged education certificate. The employer may reject the application and take lawful action. It must still:

• secure the records;

• restrict disclosure;

• maintain accurate investigation outcomes;

• retain only for an authorised purpose;

• manage vendor access.

10.2 Incorrect bank account

An employee gives an incorrect bank account number. The employer may require correction. The error does not allow it to leave the payroll database publicly accessible.

10.3 Frivolous complaint

A person submits a complaint later found to be frivolous. The Data Fiduciary still must operate an effective grievance mechanism and assess the matter properly.

Section 8(1) prevents an organisation from answering its own failure by pointing to the Data Principal’s separate misconduct.

11. “Processing undertaken by it or on its behalf”

This captures:

11.1 Direct processing

• internal HR processing;

• customer account administration;

• guest registration;

• hospital patient records;

• bank transaction processing;

• internal CCTV operation.

11.2 Outsourced processing

• payroll;

• recruitment platforms;

• identity verification;

• background checks;

• cloud hosting;

• call centres;

• SMS gateways;

• AI services;

• CCTV storage;

• biometric attendance;

• document destruction;

• marketing campaign execution.

The Data Fiduciary remains responsible across this outsourced chain.

12. Employee data must not be omitted

A recurring drafting error is to define protected information only as “Customer Data” or “End User Data.”

Many vendors also process the organisation’s workforce data, including:

• employee names and email addresses visible to IT support;

• passports provided to travel agencies;

• biometric information processed by attendance vendors;

• payroll and banking details;

• employee mailbox contents reviewed by e-discovery vendors;

• current and former employee data in litigation files;

• access-card records;

• directors’ and contractors’ personal data.

The attached practice note correctly warns that if the contractual definition excludes workforce data, the contract’s security, breach, audit, liability and deletion clauses may not apply when employee information is compromised. The definition should cover personal data of customers, employees, directors, applicants, contractors, interns and other relevant individuals to the extent processed under the engagement.

12.1 (2): Data Processor engagement under a valid contract

A Data Fiduciary may engage, appoint, use or otherwise involve a Data Processor to process personal data on its behalf for any activity related to offering goods or services to Data Principals only under a valid contract.

13. Breadth of “engage, appoint, use or otherwise involve”

The wording covers formal and informal involvement.

Section 8(2) may apply even where:

• no purchase order exists;

• the service is free;

• an employee opens an online account;

• an affiliate provides the service;

• the provider is used for a trial;

• personal data is uploaded through a browser;

• procurement did not approve the tool;

• the processor receives only temporary access.

This is especially relevant to uncontrolled cloud services and Shadow AI.

13.1 Shadow AI example

An HR manager pastes employee salary, performance and disciplinary information into a free AI drafting application.

The provider is involved in processing personal data. If no valid contract exists, the organisation may be unable to establish:

• authorised instructions;

• confidentiality;

• security safeguards;

• restrictions on model training;

• breach escalation;

• deletion;

• return of data;

• processor cooperation.

The absence of a commercial payment does not take the processing outside Section 8(2).

14. “Only under a valid contract”

The contract must be legally valid and properly incorporated.

This creates an important drafting question: should the data protection terms be inserted through:

• an amendment;

• an addendum;

• a schedule;

• clauses in the main agreement;

• a new agreement?

The answer depends on the base contract.

14.1 Amendment

An amendment changes existing language.

It may be appropriate where:

• “Confidential Information” must be expanded;

• an indemnity must include breach exposure;

• an existing security clause must be replaced;

• the liability cap must be modified;

• the termination provision must address data return.

14.2 Addendum

An addendum supplements the original agreement without rewriting it.

It may be suitable where the original agreement permits additional schedules or addenda and the parties want a separate processor framework.

14.3 No data protection addendum

Where performance does not involve personal data, inserting a detailed DPA may create confusion without improving compliance.

The attached practice note emphasises that the base contract’s amendments clause must be read before selecting the document. If the agreement requires any addition or modification to be signed by specified authorised persons, a data protection addendum executed by a junior operational contact may not be validly incorporated.

15. Signing authority

A well-drafted DPA can still fail if signed without proper authority.

The drafting team should verify:

• amendment requirements;

• required signatories;

• internal approvals;

• whether electronic signature is permitted;

• order of precedence;

• incorporation by reference;

• relationship with existing confidentiality and security terms.

If the base agreement requires modifications to be signed by the same authority that executed the agreement, procurement or a vendor manager may not have sufficient authority.

16. Contract consistency

The data protection document should not contradict the base agreement.

Common conflicts include:

The parties should include an order-of-precedence clause addressing inconsistent provisions.

17. Minimum processor-contract architecture

A robust contract should address:

17.1 Processing instructions

• precise subject matter;

• duration;

• data categories;

• Data Principal categories;

• permitted purposes;

• prohibited purposes;

• authorised systems and locations.

17.2 Personnel

• confidentiality;

• need-to-know access;

• training;

• access termination;

• privileged access.

17.3 Security

• encryption;

• masking or tokenisation;

• authentication;

• logging;

• monitoring;

• backups;

• vulnerability remediation;

• physical security;

• incident response.

17.4 Breach response

• immediate notification to the Data Fiduciary;

• preservation of evidence;

• cooperation with the Board notification;

• cooperation with Data Principal notification;

• coordination with CERT-In;

• prohibition on independent public statements without coordination, subject to legal duties.

17.5 Subprocessors

• prior approval;

• list maintenance;

• equivalent obligations;

• location transparency;

• breach escalation;

• deletion.

17.6 Data Principal support

• access;

• correction;

• erasure;

• consent withdrawal;

• grievances;

• identity verification;

• response timelines.

17.7 End of processing

• return;

• erasure;

• deletion certificate;

• treatment of backups;

• subprocessor deletion;

• survival of confidentiality and security.

17.8 Audit and evidence

• security reports;

• certifications;

• vulnerability information;

• incident records;

• right to audit;

• remediation of findings.

18. GDPR templates must be adapted

A GDPR-based DPA may provide a useful starting point. It should not be adopted through simple search and replacement.

The attached practice note identifies an especially serious problem: GDPR breach clauses often include risk thresholds that do not appear in Section 8(6) and Rule 7. A clause requiring processor notification only where a breach is “likely to result in a risk” may under-report incidents under the DPDPA.

The contract must also reflect:

• DPDPA terminology;

• Section 8(1) accountability;

• Rule 6 safeguards;

• Rule 7 notifications;

• Rule 8 retention;

• Indian-law disclosure requirements;

• CERT-In reporting where applicable.

The EDPB recommends concrete processor contracts that explain how legal requirements will be performed, rather than contracts that merely reproduce statutory text.

18.1 (3): Completeness, accuracy and consistency

Where personal data is likely to be used to make a decision that affects the Data Principal or disclosed to another Data Fiduciary, the Data Fiduciary processing it shall ensure its completeness, accuracy and consistency.

19. Triggered quality obligation

Section 8(3) is triggered in two situations:

1. PERSONAL DATA IS LIKELY TO BE USED
2. Decision affecting Disclosure to another Data Principal Data Fiduciary
3. Ensure completeness, accuracy and consistency

The obligation arises before the decision or disclosure. The organisation should not wait for harm.

20. Completeness

Completeness means that relevant context is not materially missing.

It does not require maximum collection.

20.1 Employee misconduct example

The file states:

“Employee accused of theft.”

It omits:

“Investigation found the allegation unsubstantiated.”

The first statement may be historically accurate, but the record is materially incomplete if used for promotion or reference decisions.

20.2 Applicant example

A recruitment record says the candidate lacks a required degree. The applicant previously supplied the correct certificate, but the portal failed to attach it.

A rejection based on the incomplete record may violate Section 8(3).

20.3 Customer fraud example

An account is marked fraudulent because of a disputed transaction. The business omits that the bank confirmed card cloning and cleared the customer.

The profile is incomplete.

21. Accuracy

Accuracy concerns factual correctness and appropriate updating.

Data requiring controls may include:

• bank account;

• PAN;

• address;

• attendance;

• employment status;

• dependent information;

• qualification;

• medical fitness;

• customer identity;

• fraud flags;

• CCTV matches;

• model scores.

21.1 AI output

A prediction should not be presented as an established fact.

“Model estimates a 70% likelihood of attrition” is not the same as “employee intends to resign.”

The Data Fiduciary should preserve:

• confidence;

• limitations;

• source data;

• possibility of correction;

• human review.

22. Consistency

Consistency requires reconciliation of material contradictions.

22.1 HR example

• HRMS: employee active.

• Payroll: employee terminated.

• Access control: employee on long leave.

Before denying salary or deactivating access, the organisation must resolve the conflict.

22.2 Hotel example

• booking system: guest paid.

• finance system: payment pending.

• customer support: refund approved.

A decision to block the guest should not be made until discrepancies are resolved.

23. Disclosure to another Data Fiduciary

Before disclosing data to an insurer, lender, authority or independent professional, the disclosing Data Fiduciary must ensure quality.

This applies where:

• an employer sends dependent data to an insurer;

• a bank reports transaction information;

• a former employer provides a reference;

• a recruitment agency sends candidate profiles;

• a hotel shares guest information with an independent accommodation provider;

• CCTV footage is disclosed to police.

23.1 CCTV example

A private security team exports footage labelled as showing “the suspect.” The video merely shows a person present near the event.

The Data Fiduciary should not convert an observation into a factual accusation. Descriptions and metadata must be accurate and complete.

24. Scraped data

Publicly available information may be:

• outdated;

• impersonated;

• sarcastic;

• incomplete;

• copied from another person;

• taken out of context.

A data broker that sells a scraped employment or risk profile to another Data Fiduciary must consider Section 8(3). Public accessibility is not proof of accuracy.

25. AI and data quality

Before deploying AI for consequential decisions, the Data Fiduciary should assess:

• training-data quality;

• missing fields;

• proxy variables;

• outdated records;

• false-positive rates;

• model drift;

• inconsistent source systems;

• human-review quality;

• ability to correct data;

• error propagation to recipients.

Section 8(3) does not prescribe a full AI-governance code. It nevertheless makes “the algorithm produced it” an inadequate defence where inaccurate or incomplete data affects an individual.

25.1 (4): Technical and organisational measures

A Data Fiduciary shall implement appropriate technical and organisational measures to ensure effective observance of the Act and Rules.

26. Broader than security

Section 8(4) is an accountability and governance requirement.

Security is one component. Other components include:

• legal-ground mapping;

• notice and consent systems;

• role determination;

• processor management;

• data quality;

• retention;

• deletion;

• rights workflows;

• grievance procedures;

• breach governance;

• records and evidence;

• employee training;

• internal oversight.

27. “Implement”

The organisation must move beyond paper.

28. “Appropriate”

Measures should reflect:

• data volume;

• nature of information;

• scale;

• processing purpose;

• number of people;

• use of AI;

• impact of decisions;

• children;

• public exposure;

• vendor dependence;

• threat environment;

• available technology.

The Act has no special-category definition, but higher-risk information may justify stronger measures in practice.

29. Governance structure

A mature Data Fiduciary should establish:

• accountable leadership;

• legal and privacy review;

• IT-security ownership;

• business-process owners;

• vendor governance;

• breach team;

• retention owners;

• grievance handlers;

• employee training;

• records of decisions.

A privacy office cannot achieve compliance if procurement, HR, marketing, IT, security and finance operate independently without escalation.

30. AI governance

For AI projects, appropriate measures may include:

• source and ground review;

• training-data inventory;

• processor assessment;

• prohibition on uncontrolled model training;

• testing for memorisation;

• bias and accuracy review;

• human oversight;

• output monitoring;

• prompt and log retention controls;

• exit and deletion capability;

• model-change governance.

30.1 (5): Reasonable security safeguards and Rule 6

A Data Fiduciary shall protect personal data in its possession or control, including processing undertaken on its behalf, by taking reasonable security safeguards to prevent a personal data breach.

31. Minimum Rule 6 controls

Rule 6 requires, at minimum:

• appropriate data-security measures such as encryption, masking, obfuscation or virtual tokens;

• appropriate access controls;

• logs, monitoring and review;

• detection, investigation and remediation;

• continuity measures and backups;

• one-year retention of relevant security logs and personal data for specified purposes, unless another law requires otherwise;

• processor-contract security provisions;

• technical and organisational measures ensuring safeguards are observed.

32. Risk-based application within a statutory minimum

The Rule identifies minimum categories, but implementation remains contextual.

A small marketing list and a biometric-attendance database may both require access control and monitoring, but the actual design should differ.

Biometric information may require:

• strict segregation;

• encryption;

• limited administrator access;

• strong authentication;

• export restrictions;

• template rather than raw-image storage;

• immediate revocation after exit;

• tested processor deletion.

33. Security contracts

Rule 6 expressly requires appropriate security provisions in processor contracts.

The contract should not merely say, “Vendor shall maintain reasonable security.”

It should define, where relevant:

• encryption standards;

• key management;

• identity and access management;

• logging;

• vulnerability remediation;

• backup;

• segregation;

• audit reports;

• incident escalation;

• security testing;

• deletion;

• personnel controls.

34. Workforce data

Processor contracts should cover employee and contractor data, not only customers.

Example

Examples from the attached practice note include:

• IT helpdesk tickets revealing employee contact information;

• travel agencies processing passports;

• biometric vendors;

• litigation-service providers reviewing employee mailboxes;

• payroll and insurance vendors.

35. Security retention is not universal operational retention

Rule 6’s one-year requirement should not be converted into:

“All personal data must be retained for at least one year.”

The retained information must remain tied to:

• security detection;

• investigation;

• remediation;

• prevention of recurrence;

• continuity.

It should not continue to be used for marketing, employee scoring or unrelated analytics after the original purpose ends.

35.1 (6): Personal data breach

In the event of a personal data breach, the Data Fiduciary shall intimate the Board and each affected Data Principal.

36. No express materiality threshold

Section 8(6) and Rule 7 do not reproduce the GDPR’s risk thresholds.

Under the GDPR:

• supervisory notification is generally required where the breach is likely to create risk;

• individual communication is generally required where high risk exists;

• specified exceptions may apply.

Under the DPDPA framework reflected in Section 8(6) and Rule 7:

• the Board must receive notification;

• each affected Data Principal must be informed;

• no express self-assessed low-risk exemption appears.

This difference makes it dangerous to copy a GDPR processor clause stating that notification is required only where the incident is “likely to result in risk.” The attached practice note identifies this as a serious drafting error.

37. Data Principal notification

Rule 7 requires notification:

• without delay;

• in concise, clear and plain language;

• through the user account or registered communication channel.

It must describe:

• nature, extent and timing;

• likely consequences;

• mitigation;

• protective steps;

• contact for questions.

38. Board notification

The Board must receive:

38.1 Without delay

An initial description covering:

• nature;

• extent;

• timing;

• location;

• likely impact.

38.2 Within 72 hours

Updated information covering:

• facts and circumstances;

• reasons;

• mitigation;

• responsible person, where identified;

• recurrence prevention;

• report on Data Principal notifications.

The Board may allow a longer period upon a written request.

The 72-hour period is for the detailed follow-up. It is not a licence to wait 72 hours before sending the initial intimation.

39. Parallel CERT-In obligations

A personal data breach may also be a reportable cyber incident under the Information Technology Act framework and CERT-In Directions dated 28 April 2022.

Specified cyber incidents may require reporting to CERT-In within six hours of noticing or being brought to notice.

This creates parallel tracks:

1. CYBER OR DATA INCIDENT
2. DPDPA track CERT-In track
3. Board and CERT-In within affected persons applicable six-hour period

Compliance with one does not automatically satisfy the other.

The attached practice note correctly warns that a processor notification period of 24 or 48 hours may already be too slow where the Data Fiduciary faces a six-hour CERT-In deadline. The vendor’s contractual timeframe must sit comfortably inside the shortest regulatory clock.

40. Processor escalation clause

A processor should be required to notify the Data Fiduciary:

• immediately or within a very short defined period;

• upon suspected or confirmed compromise;

• with available information;

• without waiting for a complete investigation.

The contract should require updates covering:

• affected systems;

• data categories;

• Data Principals;

• timeline;

• threat actor;

• downloads or exports;

• containment;

• logs;

• root cause;

• remediation.

A clause saying “promptly” may be too uncertain for a six-hour external deadline.

41. Multiple notification regimes

Depending on the incident, notifications may be due to:

• Data Protection Board;

• affected Data Principals;

• CERT-In;

• sector regulator;

• police;

• payment network;

• insurer;

• contractual counterparties.

The incident-response plan should identify each route separately.

42. Examples

42.1 Payroll breach

A payroll vendor exposes a spreadsheet containing employee salaries, PAN and bank details.

The employer remains responsible under Section 8(1). The vendor must escalate immediately. The employer must coordinate Board and individual notifications and assess CERT-In and other reporting.

42.2 CCTV disclosure

A security employee posts footage of an identifiable guest in a public messaging group.

This is a potential personal data breach even though no hacker was involved.

42.3 AI cross-user leak

A chatbot displays one customer’s account information to another.

Calling the event a model hallucination does not remove it from breach analysis if real personal data was disclosed.

42.4 (7): Erasure and processor deletion

43. Two erasure triggers

Erasure is required:

1. upon withdrawal of consent; or

2. when it is reasonable to assume the specified purpose is no longer served;

whichever is earlier.

Legal retention is the exception.

44. Contractual consequence

Processor contracts must require:

• cessation;

• erasure;

• return;

• deletion from active systems;

• treatment of backups;

• subprocessor deletion;

• written confirmation.

A DPA that lacks deletion provisions leaves the Data Fiduciary unable to perform Section 8(7)(b).

45. Legal retention

The Data Fiduciary should maintain a legal-retention register identifying:

• statute or regulation;

• data category;

• retention period;

• purpose;

• responsible team;

• deletion date;

• access restrictions.

General references to “legal, tax, audit and business purposes” are insufficient as retention rules.

46. Applicant records

After the vacancy concludes:

• unsuccessful applicant information should be erased unless future retention was agreed or another legal purpose exists;

• background reports should not remain indefinitely;

• recruitment vendors should erase their copies;

• AI training should not continue unless separately authorised.

47. Employee records

After employment ends, different categories may follow different schedules.

There is no sound basis for retaining the entire employee file permanently as one undifferentiated record.

48. AI data

Erasure planning should include:

• source records;

• training datasets;

• vector databases;

• prompts;

• model inputs;

• output profiles;

• embeddings;

• logs;

• processor copies;

• backups.

The Act does not prescribe machine unlearning. The absence of a mature technical solution does not justify collecting and embedding unlimited personal data without deletion planning.

48.1 (8) and Rule 8: Inactivity and deemed purpose completion

49. Two cumulative inactivity conditions

The Data Principal must neither:

• approach the Data Fiduciary for performance of the purpose; nor

• exercise rights concerning the processing;

during the prescribed period.

Both limbs matter.

A correction request may prevent operation of the second limb even if no service has been requested.

50. Third Schedule periods

Rule 8 applies specific time periods to particular classes of Data Fiduciaries and purposes identified in the Third Schedule.

The organisation must not apply those periods universally to every processing operation.

51. Forty-eight-hour notice

At least 48 hours before erasure under the prescribed inactivity mechanism, the Data Fiduciary must tell the Data Principal that the data will be erased unless she:

• logs in;

• initiates relevant contact;

• exercises rights.

This obligation concerns the Rule 8 inactivity mechanism. It is not necessarily a requirement to send 48-hour warnings before every form of purpose-based deletion.

52. One-year Rule 8(3) retention

Rule 8(3) requires retention of personal data, associated traffic data and other processing logs for a minimum of one year for purposes specified in the Seventh Schedule, followed by erasure unless longer retention is required.

The data may need to be retained in a restricted state after the original commercial purpose ends.

This should not be interpreted as permission to continue:

• marketing;

• profiling;

• recommendation;

• employee monitoring;

• model training;

• general analytics.

52.1 (9): Published business contact information

A functional privacy contact should be available to:

• current customers;

• former customers;

• applicants;

• rejected applicants;

• employees;

• former employees;

• interns;

• CCTV subjects;

• vendor personnel;

• persons without accounts.

The contact should be:

• current;

• monitored;

• capable of escalation;

• supported by trained personnel;

• accessible in relevant channels and languages.

A blank placeholder in a privacy notice is not operational compliance.

A role-based contact ordinarily provides better continuity than a particular employee’s personal email address.

52.2 (10): Effective grievance redressal

An effective mechanism must do more than receive email.

It should:

1. accept a grievance;

2. acknowledge it;

3. verify identity proportionately;

4. identify the processing activity;

5. investigate;

6. consult the relevant department or processor;

7. provide a reasoned response;

8. correct or remediate where required;

9. record closure;

10. provide escalation.

52.3 Grievances may involve

• consent;

• marketing after withdrawal;

• applicant retention;

• employee surveillance;

• incorrect payroll;

• inaccurate AI outputs;

• CCTV disclosure;

• processor breach;

• refusal to erase;

• language access;

• security concerns;

• unauthorised sharing.

52.4 AI grievance handling

A person affected by an AI-supported decision should not receive:

“The system made the decision, so no further information is available.”

The Data Fiduciary should be able to investigate:

• source data;

• data quality;

• model version;

• output;

• confidence;

• human review;

• correction;

• vendor involvement.

52.5 (11): When the Data Principal has not approached

The Data Principal must initiate contact for performance of the specified purpose.

The following should not automatically restart the inactivity period:

• unsolicited marketing email;

• background application ping;

• passive cookie activity;

• automated device signal;

• Data Fiduciary-initiated message;

• accidental app opening.

A grievance about unlawful marketing does not amount to renewed consent to that marketing.

A rights request may engage Section 8(8)(b), but it should not be mischaracterised as a new commercial engagement.

52.6 Consolidated drafting consequences of Section 8

The attached practice note’s six recurring mistakes can be mapped directly to Section 8.

52.7 Practical Section 8 contract matrix

52.8 Final interpretation

Section 8 establishes the DPDPA’s central rule of operational accountability.

The Data Fiduciary cannot outsource legal responsibility merely by outsourcing the technology. It must know what personal data exists, why it is processed, who processes it, what decisions are made, which other Data Fiduciaries receive it, how it is protected, what happens after a breach and when every copy must be erased.

The contract is important, but it is not the starting point. The starting point is the processing activity.

A valid Section 8 programme therefore requires the Data Fiduciary to:

• map factual roles before drafting;

• avoid irrelevant boilerplate;

• choose correctly between amendment, addendum and direct revision;

• verify incorporation and signing authority;

• cover customer and workforce data;

• use processor terms only for genuine processors;

• address separate and joint Data Fiduciary relationships differently;

• adapt GDPR precedents to Indian breach requirements;

• build processor reporting around the DPDPA and CERT-In clocks;

• ensure data quality before decisions and disclosures;

• implement measurable technical and organisational controls;

• operate purpose-based erasure;

• publish a working privacy contact;

• establish a grievance mechanism capable of investigation and remediation.

The controlling principle is:

Key point

The Data Fiduciary remains answerable from the moment it determines the processing purpose, through every employee, system, vendor, subprocessor, decision, disclosure and breach, until personal data that no longer has a lawful retention purpose is securely erased.