DPDPEnforced May 13, 2027Start free →
++
Chapter II Penalty: Up to ₹250 Crore for failure to take reasonable security safeguards

Section 8: General Obligations of Data Fiduciary

Comprehensive guide to all 11 sub-sections of Section 8 of the DPDP Act 2023, covering security safeguards, breach notifications, and data erasure.

Statutory Reference: Act No. 22 of 2023•Updated October 17, 2026

Statutory Text (Official Gazette)

(1) 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 may engage, appoint, use or otherwise involve a Data Processor to process personal data on its behalf for any activity related to offering of goods or services to Data Principals only under a valid contract.

(3) Where personal data processed by a Data Fiduciary is likely to be—

  • (a) used to make a decision that affects the Data Principal; or
  • (b) disclosed to another Data Fiduciary,

the Data Fiduciary processing such personal data shall ensure its completeness, accuracy and consistency.

(4) A Data Fiduciary shall implement appropriate technical and organisational measures to ensure effective observance of the provisions of this Act and the rules made thereunder.

(5) A Data Fiduciary shall protect personal data in its possession or under its control, including in respect of any processing undertaken by it or on its behalf by a Data Processor, by taking reasonable security safeguards to prevent personal data breach.

(6) In the event of a personal data breach, the Data Fiduciary shall give the Board and each affected Data Principal, intimation of such breach in such form and manner as may be prescribed.

(7) A Data Fiduciary shall, unless retention is necessary for compliance with any law for the time being in force,—

  • (a) erase personal data, upon the Data Principal withdrawing her consent or as soon as it is reasonable to assume that the specified purpose is no longer being served, whichever is earlier; and
  • (b) cause its Data Processor to erase any personal data that was made available by the Data Fiduciary for processing to such Data Processor.

Illustrations.—(I) X, an individual, registers herself on an online marketplace operated by Y, an e-commerce service provider. X gives her consent to Y for the processing of her personal data for selling her used car. The online marketplace helps conclude the sale. Y shall no longer retain her personal data. (II) X, an individual, decides to close her savings account with Y, a bank. Y is required by law applicable to banks to maintain the record of the identity of its clients for a period of ten years beyond closing of accounts. Since retention is necessary for compliance with law, Y shall retain X’s personal data for the said period.

(8) The purpose referred to in clause (a) of sub-section (7) shall be deemed to no longer be served, if the Data Principal does not—

  • (a) approach the Data Fiduciary for the performance of the specified purpose; and
  • (b) exercise any of her rights in relation to such processing,

for such time period as may be prescribed, and different time periods may be prescribed for different classes of Data Fiduciaries and for different purposes.

(9) A Data Fiduciary shall publish, in such manner as may be prescribed, the business contact information of a Data Protection Officer, if applicable, or a person who is able to answer on behalf of the Data Fiduciary, the questions, if any, raised by the Data Principal about the processing of her personal data.

(10) A Data Fiduciary shall establish an effective mechanism to redress the grievances of Data Principals.

(11) For the purposes of this section, it is hereby clarified that a Data Principal shall be considered as not having approached the Data Fiduciary for the performance of the specified purpose, in any period during which she has not initiated contact with the Data Fiduciary for such performance, in person or by way of communication in electronic or physical form.


Detailed Clause-by-Clause Breakdown

Section 8 is the operational spine of Indian data privacy law. Here is what each of its 11 sub-sections demands from your engineering architecture and business operations:


Sub-Section (1): Ultimate Accountability (No Blaming Vendors)

  • The Rule: You cannot sign away your compliance duties. If you hire a third-party marketing agency, cloud provider, analytics vendor, or freelancer who handles your user data, your company remains 100% legally responsible before the Data Protection Board.
  • Developer Takeaway: Always vet your third-party SDKs, API integrations, and cloud storage settings. If an external vendor leaks customer data, the regulator fines you, not the vendor.

Sub-Section (2): Mandatory Data Processing Agreements (DPAs)

  • The Rule: You may use a Data Processor (e.g. AWS, Razorpay, Stripe, Segment, Mailchimp) only “under a valid contract”.
  • Contract Requirement: The Act does not list what the contract must say, but Rule 6(1)(f) requires it to include reasonable security safeguards. In practice, also cover processing instructions, confidentiality, and deletion when the service ends, since Section 8(7)(b) makes you responsible for getting processors to erase data.

Sub-Section (3): Data Quality & Consistency Before Decisions

  • The Rule: If customer data is used to make a consequential decision (such as approving a loan, calculating an insurance premium, or evaluating credit risk), or shared with a partner company, you must ensure the data is complete, updated, and accurate.
  • Engineering Takeaway: Implement verification steps and validation checks so decisions are not made on stale or truncated customer profiles.

Sub-Section (4): Mandatory Technical & Organizational Architecture

  • The Rule: Compliance is not just a legal disclaimer on your website; you must implement active technical controls in your software stack.
  • Technical Standards: Role-based access control (RBAC), multi-factor authentication (MFA), least-privilege API tokens, automated logging, and encrypted backups.

Sub-Section (5): Reasonable Security Safeguards (The ₹250 Crore Penalty)

  • The Rule: You must protect personal data in your custody by deploying industry-standard security safeguards.
  • The Penalty: Failing to deploy reasonable security safeguards carries the highest penalty in the entire Act: up to ₹250 Crore.
  • Operational Standard (DPDP Rule 6): At minimum, encryption, obfuscation, masking or tokenisation; access controls; logs and monitoring to detect unauthorised access; backups for continuity; retaining logs and personal data for one year to investigate incidents; and security clauses in processor contracts. Rule 6 does not name specific standards. TLS 1.3 and AES-256 are good practice, not legal requirements.

Sub-Section (6): Mandatory Incident Reporting (The 72-Hour Rule)

  • The Rule: The era of sweeping data breaches under the rug is legally over. In any breach event, you must notify both the Data Protection Board of India and each affected individual.
  • The Penalty: Failing to notify the Board or affected users carries up to ₹200 Crore (a civil penalty, not a criminal offence).
  • Operational Standard (DPDP Rule 7): Tell affected users and the Board “without delay”. Then send the Board a detailed report within 72 hours of becoming aware of the breach, unless the Board allows longer on written request.

Sub-Section (7): Automatic Data Erasure & Downstream Purge

  • The Rule: You cannot keep customer data forever. Unless a law requires you to keep it, data must be erased when:
    1. The user withdraws consent, OR
    2. It is reasonable to assume the purpose is no longer being served (whichever comes first).
  • The Exception: Retention required by law always wins.
  • Engineering Requirement: Automated data retention cron jobs that scrub expired customer records and cascade deletion webhooks to external processors.

Statutory Case Studies (Official Gazette Illustrations):

Case Study 1: The Used Car Marketplace (Illustration I)

X (an individual) registers on Y (an online e-commerce platform) and consents to processing her personal data to sell her used car. The car is successfully sold.

Statutory Outcome: Y must no longer retain X's personal data. Once the car is sold and the deal is concluded, the purpose is fulfilled, and Y is legally required to erase her records.
Case Study 2: The Closed Bank Account (Illustration II)

X closes her savings bank account with Y (a bank). Banking laws require Indian banks to maintain client identity and transaction records for 10 years after account closure.

Statutory Outcome: Y must retain X's personal data for the mandatory 10-year period. Because retention is required by another Indian law (PMLA / RBI rules), this statutory retention requirement legally supersedes the general erasure rule.

Sub-Section (8): When a Purpose Is Deemed Over

  • The Rule: If a user neither comes back to use the service nor exercises any rights for a prescribed period, the purpose is treated as no longer served, and Section 8(7) requires erasure.
  • Rule 8 Periods: The Third Schedule sets three years of inactivity for e-commerce platforms with at least 2 crore registered users in India, online gaming platforms with at least 50 lakh, and social media platforms with at least 2 crore. Access to the user account and stored wallet balances or tokens is excluded. You must warn the user at least 48 hours before erasure.
  • Minimum Retention: Rule 8(3) also requires every Data Fiduciary to keep personal data, traffic data and processing logs for at least one year from the date of processing, even if the user deletes their account.

Sub-Section (9): Public Privacy Contact Disclosure

  • The Rule: You must publish the business contact information of your Data Protection Officer (if applicable) or a person who can answer users’ questions. Rule 9 requires it to be shown prominently on your website or app and included in every reply to a rights request.

Sub-Section (10): Accessible Grievance Redressal

  • The Rule: Every business must have an effective way for users to raise grievances. Rule 14(3) requires you to publish your response period, which cannot exceed 90 days.

Sub-Section (11): What “Not Approaching” Means

  • The Rule: A user counts as not having approached you during any period in which they did not start contact for the purpose, whether in person, electronically or on paper. Marketing emails you send do not reset the clock.

Complete Compliance Matrix for Section 8

Sub-SectionOperational RequirementEngineering Action Item
8(1)Ultimate accountability for all vendor processingAudit all external SDKs, APIs, and analytics packages
8(2)Mandatory processor contractsExecute written DPAs with every cloud, payment, and analytics tool
8(3)Data accuracy before decisionsData validation pipelines and schema constraints
8(4)Technical & organizational complianceRole-based access control (RBAC) and audit trails
8(5)Security safeguards (₹250 Cr cap)Encryption or tokenisation, access control, monitoring, 1-year log retention under Rule 6
8(6)Breach intimation (₹200 Cr cap)Automated incident response playbooks with 72-hour SLA
8(7)Erasure when consent is withdrawn or purpose ends, unless law requires retentionAutomated retention cleanup jobs & processor cascade
8(8)Purpose deemed over after a prescribed inactivity period3-year inactivity purge for large platforms, 48-hour warning under Rule 8
8(9)Contact information publicationDPO or privacy contact shown prominently on site and in rights replies
8(10)Grievance resolution channelTicketing with a published response period of 90 days or less
8(11)Meaning of “not approached”Track the last user-started contact per account
++ DPDP Compliance Scanner

Check if your website complies with Section 8

Scan your domain in seconds to detect tracking cookies, third-party analytics pixels firing before consent, and missing regional notices.