MODULE 1

Story-Based Learning

Digital Personal Data Protection Act, 2023

Chapters I – IX: Complete Statutory Framework

Case Studies:

FinEdge Digital Pvt. Ltd. · MedCare Multi-Speciality Hospital

Introduction: The FinEdge Story

FinEdge Digital Pvt. Ltd. is a Bengaluru-based fintech startup that offers instant personal loans through a mobile application. To deliver its services, FinEdge collects the following personal data from customers:

• Name
• Mobile number
• PAN
• Aadhaar
• Bank account details
• Employment information
• Location data

This module traces how each Chapter of the DPDPA applies through FinEdge's journey — from onboarding customers to handling a data breach, from exercising rights to facing enforcement action. A parallel healthcare case study (MedCare Hospital) is introduced in Chapters III onwards for comparative learning.

Chapter I — Preliminary (Sections 1–3)

Section 1 — Short Title and Commencement

The governing legislation is the Digital Personal Data Protection Act, 2023 (DPDPA). The Act comes into force through government notification on a date determined by the Central Government.

Section 2 — Definitions: Identifying the Actors

Section 2 defines the key roles and concepts that determine accountability. The following actors appear within FinEdge's ecosystem.

1. Personal Data [Section 2(t)]

Rahul downloads the FinEdge app and submits his name, PAN, Aadhaar, and bank details. All of this constitutes personal data because Rahul can be identified from it. Even his IP address recorded at login qualifies as personal data.

2. Data Principal [Section 2(j)]

Rahul is the Data Principal — the individual to whom the data relates. If Rahul were under 16, his parent or guardian would act on his behalf.

3. Data Fiduciary [Section 2(i)]

FinEdge decides why data is collected (loan assessment) and how it is processed (AI-based risk profiling). FinEdge is therefore the Data Fiduciary and bears primary compliance responsibility.

4. Data Processor [Section 2(k)]

FinEdge uses a cloud hosting provider, a third-party KYC verification service, and an SMS gateway vendor. These entities process data solely on FinEdge's instructions; they are Data Processors and do not determine the purpose of processing.

5. Personal Data Breach [Section 2(u)]

Six months after launch, a hacker accesses FinEdge's customer database and exposes PAN numbers. This constitutes a personal data breach because there is unauthorized access and disclosure of personal data.

Section 3 — Territorial Application of the Act

Processing in India

FinEdge operates in India and processes digital personal data. DPDPA applies fully.

Offline Data Converted to Digital

FinEdge conducts a physical loan mela and collects paper application forms. Once staff enter this data into the system, it becomes digital — and DPDPA applies from that point.

Extraterritorial Application

FinEdge expands to Singapore but continues offering loans to individuals in India. Even if servers are located outside India, DPDPA applies because services are offered to Indian residents.

What Is Not Covered

If Rahul saves FinEdge's customer care number in his personal phone, that is a personal domestic activity. DPDPA does not apply to personal or domestic use of data.

Chapter II — Obligations of Data Fiduciary (Sections 4–10)

This is where compliance responsibility becomes operational. Chapter II imposes enforceable duties on every Data Fiduciary.

Section 4 — Grounds for Processing Personal Data

FinEdge can process Rahul's data only if:

• There is a lawful purpose, and
• Consent has been obtained, or
• A legitimate use applies under Section 7.

Processing cannot be arbitrary. Collecting Aadhaar for marketing campaigns, for example, would likely not constitute a lawful purpose.

Section 5 — Notice

When Rahul installs the FinEdge app, the app must display a clear and accessible notice stating:

• What personal data is collected
• Why it is collected (purpose)
• With whom it will be shared
• How Rahul can withdraw consent
• Details of the grievance mechanism

Section 6 — Consent

Rahul sees two checkboxes when registering:

• ☐ I agree to loan processing
• ☐ I agree to receive marketing emails

If both boxes are blank and Rahul actively ticks them, consent is valid. If the marketing checkbox is pre-ticked, consent is not valid.

Valid consent must be:

• Free — not coerced
• Informed — based on clear notice
• Specific — for a defined purpose
• Unambiguous — no room for doubt
• Affirmative — an active act, not inaction

Withdrawal of Consent

Rahul later decides to stop receiving marketing emails and clicks 'Unsubscribe'. FinEdge must immediately stop that specific processing. However, loan repayment data may continue to be processed under a legal obligation.

Section 7 — Legitimate Uses (Processing Without Consent)

Certain categories of processing do not require separate consent:

• Regulatory reporting: FinEdge shares loan data with the RBI under statutory reporting requirements — no separate consent needed.
• Employment purpose: FinEdge processes employee salary data without requiring separate employee consent.

Section 8 — General Obligations of Data Fiduciary

This is the most operational section of the Act. FinEdge must:

• Ensure data accuracy
• Implement reasonable security safeguards
• Notify personal data breaches
• Delete data after the purpose is served
• Establish a grievance redressal mechanism

Security Safeguards

FinEdge must encrypt databases, implement access control systems, and monitor server logs. Leaving a PAN database unencrypted materially increases risk and legal exposure.

Breach Notification [Section 8(6)]

After the hacking incident, FinEdge must inform the Data Protection Board and notify all affected users, including Rahul. Failure may attract substantial monetary penalties.

Data Deletion

If Rahul fully repays his loan and no statutory retention requirement exists, FinEdge must delete the data. Financial transaction records, however, may be retained under applicable financial laws.

Grievance Mechanism

When Rahul sends an email asking what data FinEdge holds about him, FinEdge must respond through a formal, time-bound grievance system.

Section 9 — Processing of Children's Data

If a person under 18 applies for a loan, FinEdge must:

• Obtain verifiable parental consent before processing
• Avoid harmful tracking, profiling, or targeted advertising directed at children

Children receive a higher level of protection under the Act.

Section 10 — Significant Data Fiduciary

FinEdge grows rapidly and reaches 5 million users. The Central Government notifies it as a Significant Data Fiduciary (SDF). FinEdge must then:

• Appoint a Data Protection Officer (DPO)
• Conduct a Data Protection Impact Assessment (DPIA)
• Undergo periodic independent audits

Classification as an SDF significantly increases compliance obligations.

Chapter III — Rights and Duties of Data Principal (Sections 11–15)

After the data breach incident, Rahul becomes privacy-conscious and begins exercising his statutory rights under Chapter III. A parallel case from MedCare Hospital illustrates how these rights apply in a healthcare context.

Part I — FinEdge: Rahul Exercises His Rights

Section 11 — Right to Access Information

Rahul sends an email to FinEdge: "Please confirm whether you are processing my personal data and provide a summary."

Under Section 11, Rahul has the right to obtain:

• Confirmation that his data is being processed
• A summary of personal data held
• Details of processing activities
• Identities of Data Fiduciaries and Processors with whom data has been shared

FinEdge must confirm that Rahul's data is stored and disclose what data is held (PAN, Aadhaar, bank details, repayment history) and whether it has been shared with KYC vendors, cloud providers, or the RBI.

Section 12 — Right to Correction and Erasure

Rahul notices his employment status is recorded as 'Self-employed' instead of 'Salaried'. He submits a correction request.

Under Section 12, Rahul can require FinEdge to:

• Correct inaccurate data
• Complete incomplete data
• Update outdated data
• Erase data no longer necessary for the original purpose

FinEdge must verify the correction, update the database, maintain an audit trail, and confirm the update to Rahul. If Rahul closes his account after fully repaying his loan, he may request erasure — unless financial laws mandate retention.

Section 13 — Right to Grievance Redressal

If FinEdge fails to respond to Rahul's correction request, he may:

• File a grievance internally through FinEdge's grievance mechanism
• If dissatisfied, escalate the matter to the Data Protection Board

FinEdge must maintain a dedicated grievance email, an online complaint form, and a time-bound response system. Failure to establish this mechanism violates both Section 8 and Section 13.

Section 14 — Right to Nominate

Rahul nominates his wife as nominee. In the event of his death, the nominee may request deletion of unnecessary personal data and exercise access rights on his behalf. This ensures continuity of privacy protection beyond the Data Principal's lifetime.

Section 15 — Duties of Data Principal

The DPDPA balances rights with responsibilities. Rahul must not:

• Impersonate another person
• Provide false information to FinEdge
• File frivolous or vexatious complaints

If Rahul knowingly submits incorrect income details to obtain a higher loan, he breaches his statutory duty. Rights cannot be exercised fraudulently.

Part II — MedCare Multi-Speciality Hospital: A Healthcare Perspective

MedCare Hospital operates electronic medical records (EMR), diagnostic labs, and insurance claim processing. Patient: Mrs. Anita Sharma.

Section 11 — Access Rights in Healthcare

Mrs. Sharma requests: "Provide a full copy of my medical records and details of who has accessed them." MedCare must provide her diagnostic history, stored medical records, and names of third parties such as the insurance TPA. Healthcare data is highly sensitive — transparency is critical.

Section 12 — Correction and Erasure in Healthcare

Mrs. Sharma finds her blood group recorded incorrectly. The hospital must update the EMR, log the correction, and inform relevant departments. If she requests deletion of her medical history, the hospital may lawfully refuse full erasure if medical retention laws require preservation.

Section 13 — Grievance Redressal in Healthcare

Mrs. Sharma complains that unauthorized staff accessed her medical file. The hospital must investigate access logs, respond formally, and provide an explanation. If dissatisfied, she may approach the Data Protection Board.

Section 14 — Nomination

Mrs. Sharma nominates her son. In case of her incapacity, he may request medical record access and exercise correction rights.

Section 15 — Duties of Data Principal (Healthcare)

Mrs. Sharma must provide accurate medical information, not suppress critical details during treatment, and not file malicious complaints. False medical information may endanger treatment and violate statutory duty.

Comparative Snapshot: FinEdge vs. MedCare

Both are Data Fiduciaries. Both must comply with Sections 11–15. The context changes the risk profile — not the legal framework.

Chapter IV — Transfer Restrictions and Exemptions (Sections 16–17)

Chapter IV addresses two major areas: restriction on cross-border data transfer (Section 16) and statutory exemptions from certain compliance obligations (Section 17).

Section 16 — Restriction on Transfer of Personal Data Outside India

Cross-border data transfer is generally permitted under DPDPA unless the Central Government issues a notification restricting transfer to specific countries or territories.

FinEdge currently stores customer data on a cloud server in Singapore. This is permitted unless the Government notifies that transfers to that jurisdiction are restricted.

Section 16(2): If any other Indian law provides stricter data localisation requirements — for example, RBI regulations for financial institutions — that law will prevail over DPDPA.

Section 17 — Exemptions from Certain Provisions

Section 17 specifies situations where Chapter II (Obligations), Chapter III (Rights), and Section 16 (Transfer Restrictions) may not apply. These exemptions are conditional and limited — they do not confer blanket immunity.

Section 17(1)(a) — Legal Rights and Claims

Processing necessary to enforce a legal right or claim is exempt. If Rahul defaults on his loan, FinEdge may process his personal data to ascertain assets and initiate recovery proceedings — even if Rahul has withdrawn consent.

Section 17(1)(b) — Courts, Tribunals and Regulatory Bodies

Processing for judicial, quasi-judicial, regulatory, or supervisory functions is exempt to the extent necessary. When the Data Protection Board processes Mrs. Sharma's medical data during an inquiry, that processing is exempt.

Section 17(1)(c) — Prevention and Investigation of Offences

Processing for prevention, detection, investigation, or prosecution of offences is exempt. If police request FinEdge's customer data to investigate fraud, processing for that investigation is exempt — though FinEdge's general security obligations remain.

Section 17(1)(d) — Foreign Data of Non-Residents

If the Data Principal is outside India and processing occurs pursuant to a contract with a foreign entity, certain provisions may not apply. For example, FinEdge providing backend processing for UAE customers of a UAE lender may qualify for this exemption.

Section 17(1)(e) — Corporate Restructuring

Processing necessary for a court- or tribunal-approved merger, amalgamation, or demerger is exempt. If FinEdge merges with another fintech company and customer data transfers under a court-approved scheme, this is permitted.

Section 17(1)(f) — Loan Default and Financial Information

Processing to ascertain the financial information, assets, or liabilities of a defaulter is exempt. If Rahul defaults, FinEdge may check his CIBIL score and verify asset holdings even if he objects.

Section 17(2)(a) — State Instrumentalities and Sovereignty

The Central Government may notify certain State instrumentalities as exempt where processing is in the interest of sovereignty, security, public order, or friendly relations with foreign States. An intelligence agency processing data for national security may qualify — but only through a formal Government notification.

Section 17(2)(b) — Research and Statistical Purposes

Processing for research, archiving, or statistical purposes is exempt if the data is not used to make a decision affecting a specific Data Principal and if prescribed standards are followed. MedCare's anonymized cancer research study, where data is aggregated and no individual patient is affected, may qualify.

Section 17(3) — Relaxations for Startups and Certain Fiduciaries

The Government may notify startups or certain classes of Data Fiduciaries to exempt them from notice requirements (Section 5), certain Section 8 obligations, SDF requirements (Section 10), or the right to access (Section 11). This provides regulatory flexibility for emerging businesses.

Section 17(5) — Temporary Transitional Exemption (5 Years)

Within five years of the Act's commencement, the Government may notify that certain provisions shall not apply to specific Data Fiduciaries. This allows phased implementation of the compliance framework.

Chapter V — Data Protection Board of India (Sections 18–26)

After the PAN data breach, Rahul asks: "Should I file an FIR? Should I go to a civil court? Who will hold FinEdge accountable?" Chapter V answers these questions by establishing a specialized adjudicatory body.

Rahul's Enforcement Options: Step-by-Step

Step 1 — Can Rahul Go to the Police?

No. The DPDPA does not create criminal offences. It provides only for civil monetary penalties. There is no arrest provision, no imprisonment under DPDPA, and no criminal trial mechanism under this Act. Police cannot try FinEdge for a DPDPA violation.

Step 2 — Can Rahul File a Civil Suit?

No. Under Section 25 (Bar of Jurisdiction), civil courts cannot entertain matters that the Data Protection Board is empowered to determine. Ordinary courts have no jurisdiction over DPDPA contraventions.

Step 3 — Where Must Rahul File?

Rahul must file a complaint before the Data Protection Board of India — the specialized regulatory adjudicating authority created by the Act.

Section 18 — Establishment of the Data Protection Board of India

The Central Government shall establish the Data Protection Board of India. The Board functions digitally and is the primary adjudicating authority under DPDPA — not a traditional civil court, but a specialized regulatory body.

Section 19 — Composition and Appointment

The Board consists of a Chairperson and other Members appointed by the Central Government. Qualifications and service conditions are prescribed by rules. This ensures regulatory expertise and institutional accountability.

Section 20 — Functions of the Board

The Board may:

• Inquire into complaints from Data Principals
• Determine whether non-compliance has occurred
• Direct urgent remedial measures
• Impose monetary penalties
• Perform other prescribed regulatory functions

All proceedings must adhere to principles of natural justice.

In the MedCare case, the Board may examine access logs, role-based access controls, and grievance response records to determine whether Sections 8 and 13 were violated.

Section 21 — Powers of the Board

During an inquiry, the Board may call for information, require production of documents, summon records, and seek explanations. In the FinEdge case, the Board may demand server logs, cybersecurity audit reports, breach timeline documentation, and vendor agreements. Refusing or delaying production may aggravate liability.

Section 22 — Voluntary Undertaking

Before a final order, a Data Fiduciary may offer a voluntary undertaking — for example, committing to security upgrades, establishing a compensation mechanism, appointing an external auditor, or implementing structural compliance reforms.

If accepted, proceedings may be concluded subject to compliance. If the undertaking is later breached, the inquiry may resume. MedCare might offer mandatory staff retraining, a system upgrade, and quarterly compliance audits in lieu of a harsher penalty.

Section 23 — Appeal

Any person aggrieved by a Board order may appeal to the Appellate Tribunal (currently TDSAT). A further appeal lies to the Supreme Court of India.

If the Board imposes ₹40 crore on FinEdge and FinEdge believes this is disproportionate, it may appeal to TDSAT and, if still aggrieved, to the Supreme Court.

Section 24 — Orders of the Board

The Board may impose monetary penalties, direct corrective actions, mandate compliance steps, and issue binding directions. All orders are enforceable.

Section 25 — Bar of Jurisdiction

Civil courts cannot adjudicate DPDPA violations. The Board holds exclusive jurisdiction. Rahul cannot file a civil suit or seek criminal prosecution under DPDPA — his forum is the Data Protection Board. If hacking occurred, police may separately prosecute the hacker under the IT Act or BNS.

Section 26 — Alternative Dispute Resolution

The Board may, where appropriate, direct mediation or other dispute resolution methods to promote efficient resolution in suitable cases.

Schedule — Monetary Penalties

Penalties may extend up to ₹250 crore depending on the contravention. Common grounds for penalty include:

• Failure to implement reasonable security safeguards
• Failure to notify a personal data breach
• Violation of children's data provisions
• Non-compliance as a Significant Data Fiduciary

Penalty determination considers: nature and gravity of the breach, duration, repetition, mitigation efforts, and the type of personal data affected. There is no imprisonment under DPDPA.

Chapter VI — Powers, Functions and Procedure of the Board (Sections 27–28)

Section 27 — Powers and Functions of the Board

Section 27(1) — Inquiry on Contravention

If the Board has reason to believe that a person has contravened the provisions of the Act, it may conduct an inquiry, determine non-compliance, and proceed accordingly. In the FinEdge case, after receiving a complaint about delayed breach notification, the Board may examine the breach timeline and check compliance records to determine whether Section 8(6) was violated.

Section 27(2) — Principles of Natural Justice

The Board must issue notice, give the concerned party an opportunity to be heard, consider all evidence, and pass a reasoned order. The Board cannot impose a penalty without first informing the accused party and allowing them to submit a defence.

Section 27(3) — Digital Proceedings

Proceedings may be conducted entirely in digital format — including electronic filing, virtual hearings, and digital submission of evidence. MedCare Hospital, for example, may submit access logs, internal audit reports, and grievance records through an electronic portal.

Section 27(4) — Power to Call for Information

The Board may require production of documents, call for records, and seek explanations. Failure to cooperate may worsen the outcome for the Data Fiduciary.

Section 27(5) — Civil Court Powers (Limited)

While not a traditional civil court, the Board may exercise certain civil court-equivalent powers for inquiry purposes, including summoning documents and requiring information.

Section 28 — Procedure to be Followed by the Board

Section 28(1) — Initiation of Action

The Board may act on a complaint by a Data Principal, on a reference by the Government, or on its own initiative (suo motu) if a contravention is evident — for example, if media reports a massive data breach by FinEdge even without an individual complaint being filed.

Section 28(2) — Factors for Determining Penalty

Before imposing a penalty, the Board considers the nature and gravity of the breach, its duration, whether it is repetitive, mitigation efforts undertaken, and the type of personal data affected. The penalty must be proportionate.

Section 28(3) — Opportunity to be Heard

The person concerned must be given a full opportunity to present a defence, submit evidence, and explain any mitigating factors before a penalty is imposed.

Section 28(4) — Orders of the Board

The Board may impose monetary penalties, issue corrective directions, and require specific compliance measures. All orders are binding and enforceable.

Practical Illustration: FinEdge

• Complaint filed for delayed breach notification.
• Board issues a formal notice to FinEdge.
• FinEdge submits server logs, notification emails, and cybersecurity audit report.
• Board finds: notification was delayed by 10 days; encryption existed but patch management was deficient.
• Board imposes a monetary penalty and directs FinEdge to upgrade its security framework.

Practical Illustration: MedCare Hospital

Complaint: Unauthorized staff accessed patient data. The Board examines access logs, role-based permissions, and the grievance mechanism. It concludes the access resulted from an internal misconfiguration, but that corrective measures were taken promptly. Outcome: moderate penalty plus a direction for staff training and quarterly audits.

Chapter VII — Appeal and Alternate Dispute Resolution (Sections 29–32)

Chapter VII establishes the right of appeal, sets out the procedure before the Appellate Tribunal, and provides for mediation and voluntary undertaking as alternative resolution mechanisms.

Section 29 — Appeal to Appellate Tribunal

Section 29(1) — Right to Appeal

Any person aggrieved by an order or direction of the Board may appeal to the Appellate Tribunal. If the Board imposes ₹50 crore on FinEdge and directs a redesign of its consent architecture, FinEdge may appeal to TDSAT.

Section 29(2) — Time Limit

The appeal must be filed within 60 days from receipt of the Board's order, in the prescribed form and with the prescribed fee. If FinEdge receives the order on 1 March, the appeal must be filed by 30 April.

Section 29(3) — Delay Condonation

The Tribunal may entertain a late appeal if sufficient cause is shown. If MedCare files after 70 days due to a serious system outage, the Tribunal may condone the delay if satisfied.

Section 29(4) — Powers of Tribunal

After hearing both parties, the Tribunal may confirm, modify, or set aside the Board's order. The Tribunal could, for example, reduce FinEdge's penalty from ₹50 crore to ₹30 crore.

Section 29(6) — Time for Disposal

The Tribunal shall endeavour to dispose of appeals within 6 months. If an appeal filed on 1 April is not decided by 30 September, the Tribunal must record reasons for the delay.

Section 29(9) — Further Appeal to Supreme Court

If a party is aggrieved by the Tribunal's order, Section 18 of the TRAI Act applies — providing a further appeal to the Supreme Court of India.

Section 29(10) — Digital Functioning

The Tribunal shall function as a digital office. All filing, hearings, and pronouncements of orders are digital by design. FinEdge may file electronically and attend a virtual hearing.

Section 30 — Execution of Orders

An order of the Appellate Tribunal is executable as a decree of a civil court. If FinEdge fails to pay a ₹40 crore penalty upheld by the Tribunal, the Tribunal may transmit the order to a civil court with local jurisdiction — for instance, a Mumbai civil court if FinEdge is registered there — for execution.

Section 31 — Mediation

If the Board believes a complaint may be resolved through mediation, it may direct the parties to attempt resolution through a mutually agreed mediator. In the MedCare case, rather than full adjudication, the Board might suggest mediation. The hospital could apologize, offer compensation, and upgrade its systems — resolving the matter without penalty proceedings.

Section 32 — Voluntary Undertaking

Section 32(1) — Acceptance

At any stage of proceedings under Section 28, the Board may accept a voluntary undertaking from a Data Fiduciary. Before a final penalty, FinEdge might offer immediate cybersecurity overhaul, a third-party audit, and a compensation framework for affected users.

Section 32(2) — Contents

The undertaking may include taking specific actions within a timeframe, refraining from certain activities, or publicly disclosing the undertaking. FinEdge might commit to appointing an external DPO within 30 days and suspending targeted marketing until a compliance review is complete.

Section 32(4) — Bar on Proceedings

Once a voluntary undertaking is accepted, proceedings are barred in relation to the contents of the undertaking — except in the event of a breach.

Section 32(5) — Breach of Undertaking

If the undertaking is not complied with, it is deemed a breach of the Act and the Board may resume proceedings after providing an opportunity of hearing. If FinEdge promised an audit within 30 days but fails to conduct one, the Board may reimpose proceedings and impose a penalty.

Integrated Enforcement Flow

Complaint → Board Inquiry → Voluntary Undertaking Accepted → Compliance

If undertaking is breached → Fresh Proceedings → Penalty

Or: Board Order → Appeal to Appellate Tribunal → Tribunal Decision → Supreme Court

Chapter VIII — Penalties and Adjudication (Sections 33–34)

Chapter VIII is the enforcement backbone of the DPDPA. It defines when penalties may be imposed, how penalty amounts are determined, and where penalty proceeds are deposited.

Section 33 — Penalties

Section 33(1) — Imposition of Monetary Penalty

If the Board, after completing an inquiry, determines that a person has committed a significant breach of the Act or Rules, it may impose a monetary penalty as specified in the Schedule — provided the person has first been given an opportunity to be heard.

Section 33(2) — Factors for Determining Penalty Amount

The Board considers the following factors when calculating the appropriate penalty:

(a) Nature, Gravity and Duration of the Breach

A minor, short-term breach attracts a lower penalty. A systemic, long-term breach attracts a higher penalty. FinEdge ignoring security patches for a year is an aggravating factor.

(b) Type and Nature of Personal Data Affected

Sensitive personal data such as medical records or financial information increases seriousness. MedCare's breach of medical records would be treated with greater severity.

(c) Repetitive Nature

Prior compliance warnings or repeat violations may increase the penalty. If FinEdge had earlier been warned about defective consent mechanisms, a repeat infraction would attract a higher sanction.

(d) Gain or Avoidance of Loss

If the breach resulted in financial gain or avoided the cost of compliance, the penalty is stricter. Skipping security upgrades to save ₹10 crore is an aggravating factor.

(e) Mitigation Efforts

Prompt containment of the breach, immediate user notification, and proactive corrective action are mitigating factors. MedCare immediately suspending access and retraining staff would be weighed favourably.

(f) Proportionality and Deterrence

The penalty must be proportionate to the breach, effective as a deterrent, and not arbitrary.

(g) Likely Impact on the Person

The Board considers the financial impact of the penalty. A large multinational may absorb a higher penalty; a small startup would be assessed proportionally.

Section 34 — Penalty Credited to Consolidated Fund of India

All penalties imposed under the Act are credited to the Consolidated Fund of India. The penalty amount does not go to the complainant directly, nor does it remain with the Board. Rahul does not automatically receive compensation from a ₹40 crore penalty imposed on FinEdge. Any separate compensation claim would be a distinct legal matter under IT Act Section 43.

Chapter IX — Miscellaneous (Sections 35–44)

The final chapter contains structural, protective, interpretative, rule-making, and transitional provisions that complete the statutory framework of the DPDPA.

Section 35 — Protection of Action Taken in Good Faith

No suit, prosecution, or other legal proceeding shall lie against the Central Government, the Board, its Chairperson, Members, officers, or employees for actions done or intended to be done in good faith under the Act. FinEdge's remedy for a ₹50 crore penalty is an appeal under Section 29 — not a personal case against Board members.

Section 36 — Power to Call for Information

The Central Government may require the Board, any Data Fiduciary, or any intermediary to furnish information for purposes of the Act. Following repeated breaches in the fintech sector, the Government may call for compliance reports from FinEdge and sector-wide data from multiple platforms.

Section 37 — Power to Block Access

This is a significant enforcement provision.

Section 37(1): If the Board has imposed monetary penalties on a Data Fiduciary in two or more instances and advises that blocking access is necessary in the public interest, the Central Government may — after providing a hearing — direct blocking of access to information hosted on computer resources that enable the Data Fiduciary to offer goods or services in India.

If FinEdge repeatedly violates consent provisions, fails to implement safeguards, and ignores penalties, the Board may recommend blocking and the Government may direct app stores and ISPs to block public access to FinEdge's platform.

Section 37(2): Every intermediary must comply with such a blocking direction.

Section 38 — Consistency with Other Laws

The DPDPA operates in addition to other laws. In the event of a conflict, the DPDPA prevails to the extent of the conflict. If another law allows broader data sharing without safeguards but DPDPA imposes stricter requirements, DPDPA provisions govern.

Section 39 — Bar of Jurisdiction

No civil court shall entertain any suit regarding matters that the Board is empowered to determine. No injunction may be granted against actions taken under the Act. If the Board initiates an inquiry against MedCare, the hospital cannot approach a civil court to halt the proceedings — it must follow the statutory appeal mechanism.

Section 40 — Power to Make Rules

The Central Government may make rules to carry out the purposes of the Act, including rules governing:

• Notice format (Section 5)
• Consent Manager regulation
• Breach reporting format and timelines
• Verifiable parental consent
• DPIA requirements
• DPO publication format
• Appeal procedure
• Board procedures and technical measures

If Rules prescribe breach reporting within 72 hours, FinEdge must comply with that specific timeline.

Section 41 — Laying of Rules Before Parliament

All Rules and certain Notifications must be laid before Parliament, which may modify or annul them. This ensures democratic oversight of subordinate legislation.

Section 42 — Power to Amend Schedule (Penalty Amounts)

The Government may amend penalty amounts by notification — but cannot increase any penalty to more than twice the original specified amount. If the Schedule currently specifies ₹250 crore as the maximum, it cannot be increased beyond ₹500 crore through notification.

Section 43 — Power to Remove Difficulties

If difficulty arises in implementing the Act, the Government may issue an order to remove it — provided the order does not contradict the Act, is issued within three years of commencement, and is laid before Parliament.

Section 44 — Amendments to Other Acts

Section 44 amends three existing statutes to align them with the DPDPA:

• TRAI Act, 1997 — amended to designate TDSAT as the Appellate Tribunal for DPDPA appeals.
• Information Technology Act, 2000 — Section 43A (compensation for failure to protect data) is omitted; DPDPA is inserted into the overriding clause.
• Right to Information Act, 2005 — amended to align personal information protection with DPDPA principles.

Before the DPDPA, data protection compensation was sought under IT Act Section 43A. The DPDPA is now the primary data protection legislation in India.

Integrated Enforcement Scenario: The Full FinEdge Arc

• FinEdge suffers a data breach and delays notification — first penalty imposed.
• FinEdge continues to use defective consent mechanisms — second penalty imposed.
• Board advises the Government that blocking access is in the public interest.
• Government issues a blocking order after providing FinEdge a hearing.
• Intermediaries (app stores, ISPs) comply. FinEdge's platform is blocked in India.

This sequence demonstrates the full enforcement reach of the DPDPA — from initial inquiry to platform-level sanctions.

Consolidated Summary: DPDPA at a Glance

Final Conceptual Takeaway

The DPDPA is not merely about obtaining consent. It creates a comprehensive governance framework built on:

• Transparency — clear notice and accessible grievance mechanisms
• Accountability — defined roles for Fiduciaries, Processors, and Principals
• Security — mandatory safeguards and breach notification
• Rights — access, correction, erasure, nomination
• Enforcement — a specialized Board with monetary penalties up to ₹250 crore
• Risk management — DPIA, SDF classification, and sectoral alignment
• Democratic oversight — Parliamentary scrutiny of rules and notifications

Through the FinEdge and MedCare stories, this module has traced the complete compliance cycle: from onboarding a customer and collecting consent, to handling a breach, defending a Board inquiry, and — in a worst-case scenario — facing platform-level sanctions under Section 37.

Understanding this cycle is essential for lawyers, Data Protection Officers, compliance professionals, and organizational leaders operating in India's digital economy.

MODULE 2

Story-Based Learning

Digital Personal Data Protection Rules, 2025

Rules 1 – 23 & All Schedules: Complete Regulatory Framework

Case Studies:

FinEdge Digital Pvt. Ltd. · MedCare Multi-Speciality Hospital

Introduction: The FinEdge Story Continues

FinEdge Digital Pvt. Ltd., now a fast-growing Bengaluru-based fintech startup with over 20 lakh registered users, has successfully navigated the Digital Personal Data Protection Act, 2023 (DPDPA). Now, the Government of India has notified the Digital Personal Data Protection Rules, 2025 (the Rules) through Gazette Notification G.S.R. 846(E) dated 13 November 2025. The Rules operationalise the Act by prescribing specific procedures, standards, timelines, and mechanisms.

This module traces how each Rule of the DPDP Rules, 2025 applies through FinEdge’s journey — from redesigning consent notice screens to handling breach reporting timelines, from operationalising children’s consent to meeting Significant Data Fiduciary obligations. A parallel healthcare case study (MedCare Hospital) is introduced for comparative learning.

Rule 1 — Short Title & Commencement

The FinEdge Context

FinEdge’s legal counsel has been tracking the DPDPA since 2023. With the Rules now notified, FinEdge must plan its compliance roadmap based on which Rules take effect immediately and which are deferred.

What Rule 1 Says

• These Rules are called the Digital Personal Data Protection Rules, 2025.
• Different Rules start on different dates:
• Rules 1, 2 and 17 to 21: effective immediately on publication (Board governance, definitions).
• Rule 4 (Consent Manager registration): effective one year after publication.
• Rules 3, 5 to 16, 22 and 23 (notice, safeguards, breach reporting, children’s consent, rights, appeals, etc.): effective eighteen months after publication.

Rule 2 — Definitions

The FinEdge Context

FinEdge operates across mobile apps, its website, and partner integrations. Understanding the precise meaning of terms like ‘user account’ and ‘verifiable consent’ determines how FinEdge designs its technology flows.

What Rule 2 Says

• Rule 2(1)(a): “Act” means the Digital Personal Data Protection Act, 2023.
• Rule 2(1)(b): “Techno-legal measures” refers to measures under Rules 20 and 22 (digital-first proceedings).
• Rule 2(1)(c): “User account” includes any online account identity — email, mobile number, profile, handle, etc.
• Rule 2(1)(d): “Verifiable consent” means consent as specified in Rule 10 or Rule 11.
• Rule 2(2): Terms defined in the Act but not in the Rules carry the same Act definitions.

Rule 3 — Notice to Data Principal

The FinEdge Context

When Rahul installs the FinEdge app, the app’s privacy notice is the first and most critical communication. Rule 3 prescribes exactly what that notice must contain and how it must be structured.

What Rule 3 Says

• Rule 3(a): The notice must be understandable on its own — not buried inside other documents or general terms and conditions.
• Rule 3(b): The notice must be clear, plain language, and must include at minimum:
• Rule 3(b)(i): An itemised description of the personal data being processed (not just categories — specific data items).
• Rule 3(b)(ii): The specified purpose(s) and what service/use is enabled by such processing.
• Rule 3(c): The notice must provide links or means for the Data Principal to:
• Rule 3(c)(i): Withdraw consent easily (as easy as giving consent — no dark patterns).
• Rule 3(c)(ii): Exercise rights under the Act (access, correction, erasure, grievance).
• Rule 3(c)(iii): Make a complaint to the Data Protection Board.

Rule 4 — Registration & Obligations of Consent Manager

The FinEdge Context

FinEdge is exploring a partnership with ConsentBridge, a platform that claims to manage consent centrally for multiple financial services. Before FinEdge relies on ConsentBridge, it must verify whether ConsentBridge is a registered Consent Manager.

What Rule 4 Says

• Rule 4(1): Eligible entities can apply to the Data Protection Board to register as a Consent Manager, subject to conditions in the First Schedule (Part A).
• Rule 4(2): The Board may inquire into eligibility and either register the applicant (publishing details publicly) or reject the application with reasons.
• Rule 4(3): Registered Consent Managers must follow obligations listed in the First Schedule (Part B).
• Rule 4(4): If the Board finds non-adherence, it can direct corrective measures after a hearing.
• Rule 4(5): The Board may suspend or cancel registration and issue directions to protect Data Principals, with reasons recorded after a hearing.
• Rule 4(6): The Board can require the Consent Manager to furnish information.

First Schedule — Part A: Conditions to Register as a Consent Manager

• Must be a company incorporated in India.
• Must have adequate technical, operational, and financial capacity.
• Net worth must be at least Rs. 2 crore.
• Business volume, capital structure, and earning prospects must be adequate.
• Directors and senior management must have good reputation and integrity.
• Company documents (MoA/AoA) must include provisions to follow key obligations (especially conflict of interest controls) and can be changed only with Board approval.
• Proposed operations should be in the interest of Data Principals.
• Independent certification must confirm the platform meets Board-published standards.

First Schedule — Part B: Obligations of a Consent Manager

• Provide a platform for individuals to give, manage, review, and withdraw consent across services.
• Ensure that personal data made available cannot be read by the Consent Manager itself.
• Maintain records of consent given/denied/withdrawn, notices linked to consent requests, and data sharing with other Data Fiduciaries.
• Give Data Principals access to these records in machine-readable form on request; retain records for at least 7 years.
• Provide services primarily through a website or app (or both).
• Must not subcontract or assign obligations to others.
• Take reasonable security safeguards to prevent personal data breaches.
• Act in a fiduciary capacity for the individual — prioritise the user’s best interests.
• Avoid conflicts of interest with Data Fiduciaries (including promoters and key managerial personnel).
• Publish key transparency information: promoters/directors, shareholders over 2%, related corporate holdings.
• Maintain effective audit mechanisms and report results to the Board.
• Must not transfer control (sale/merger) without prior Board approval.

Rule 5 — State Processing for Subsidy/Benefit/Service/Certificate/Licence/Permit

The FinEdge Context

FinEdge partners with a State Government’s Direct Benefit Transfer (DBT) programme to disburse subsidised loans. The State’s nodal agency processes beneficiary data. Rule 5 governs how State entities must handle this processing.

What Rule 5 Says

• Rule 5(1): State processing under this Rule must follow standards in the Second Schedule.
• Rule 5(2): Clarifies what constitutes benefits provided under law, policy, or public funds:
• Rule 5(2)(a): Under law (statutory power/function of a government body).
• Rule 5(2)(b): Under policy/instructions (executive power of the government).
• Rule 5(2)(c): Using public funds (Consolidated Fund/Public Account or local authority funds).

Second Schedule — Standards for State Processing

• Processing must be lawful.
• Use data only for the permitted government purposes mentioned in the law/rules.
• Collect and process only the data necessary for those purposes (data minimisation).
• Make reasonable efforts to keep data complete, accurate, and consistent.
• Keep data only as long as needed for the purpose or as required by law.
• Use reasonable security safeguards to prevent data breaches (including when processors are involved).
• Where required, inform the individual and provide: (i) business contact details for queries; (ii) link to website/app to exercise rights; and (iii) follow applicable standards/policies.
• Ensure accountability of the person/entity deciding purpose and means of processing.

Rule 6 — Reasonable Security Safeguards

The FinEdge Context

FinEdge has experienced a near-miss security incident — an unauthorised login attempt on its admin portal. This triggers a comprehensive review of its security architecture. Rule 6 provides the specific safeguards FinEdge must implement.

What Rule 6 Says

• Rule 6(1)(a): Use measures like encryption, obfuscation, masking, or virtual tokens to protect personal data.
• Rule 6(1)(b): Implement access controls for all systems used by the Data Fiduciary or Data Processor.
• Rule 6(1)(c): Maintain logs, monitoring, and review mechanisms to detect unauthorised access and prevent recurrence.
• Rule 6(1)(d): Ensure backups and continuity arrangements if data availability or integrity is compromised.
• Rule 6(1)(e): Retain logs and relevant personal data for at least one year (unless other law requires longer).
• Rule 6(1)(f): Include security safeguard clauses in contracts between Data Fiduciary and Data Processor.
• Rule 6(1)(g): Adopt technical and organisational measures (policies, training, governance).
• Rule 6(2): “Computer resource” has the same meaning as in the Information Technology Act, 2000.

Rule 7 — Intimation of Personal Data Breach

The FinEdge Context

FinEdge’s security team detects at 11:00 PM that an unauthorised actor has accessed its customer database, exposing PAN numbers of 15,000 users. The incident response team activates. Rule 7 governs exactly what FinEdge must do next.

What Rule 7 Says

Track 1: Informing Affected Data Principals

• Rule 7(1): Inform each affected Data Principal ‘without delay’ (via user account or registered communication), including:
• Rule 7(1)(a): What happened — nature, extent, and timing of the breach.
• Rule 7(1)(b): Likely consequences for the affected individual.
• Rule 7(1)(c): Mitigation actions taken or being taken.
• Rule 7(1)(d): Safety steps the individual should take (e.g., change password, monitor statements).
• Rule 7(1)(e): Contact details of a responsible person within the organisation.

Track 2: Reporting to the Data Protection Board

• Rule 7(2)(a): Inform the Board without delay — basic description including likely impact.
• Rule 7(2)(b): Within 72 hours (or longer if Board allows), provide a detailed report including:
• Rule 7(2)(b)(i): Updated and detailed information about the breach.
• Rule 7(2)(b)(ii): Events, circumstances, and reasons leading to the breach.
• Rule 7(2)(b)(iii): Mitigation measures implemented or proposed.
• Rule 7(2)(b)(iv): Findings about who caused the breach (if known).
• Rule 7(2)(b)(v): Remedial measures to prevent recurrence.
• Rule 7(2)(b)(vi): Report on user intimations issued.

Rule 8 — Erasure When Purpose is No Longer Served

The FinEdge Context

Rahul closed his FinEdge loan account two years ago after repayment. His data still resides in FinEdge’s systems. FinEdge’s data retention team must now determine how long to retain data and when erasure is mandatory under Rule 8.

What Rule 8 Says

• Rule 8(1): For certain classes/purposes (Third Schedule), erase personal data after the specified time if the user is inactive, unless another law requires retention.
• Rule 8(2): Inform the user at least 48 hours before erasure; allow them to log in, contact the organisation, or exercise rights to stop or defer erasure.
• Rule 8(3): Retain personal data and traffic data/logs for at least one year from processing date (for Seventh Schedule purposes), then erase unless other law or Government notification requires longer retention.

Third Schedule — Retention Limits for Large Platforms

• Applies to: (i) e-commerce entities with 2 crore or more registered users in India; (ii) online gaming intermediaries with 50 lakh or more registered users in India; (iii) social media intermediaries with 2 crore or more registered users in India.
• General rule: Do not keep personal data beyond 3 years from the last time the user engaged with the platform for that purpose, or from the start of the Rules — whichever is later.
• Exceptions: Data needed to let the user access their account, or access virtual tokens/credits stored on the platform.

Rule 9 — Contact Details for Processing-Related Queries

The FinEdge Context

Priya, a FinEdge customer, wants to know what personal data FinEdge holds about her. She cannot find any contact information on the app to raise her query. This is a Rule 9 violation.

What Rule 9 Says

• Publish business contact details of the Data Protection Officer (DPO) — or a responsible person, if no DPO is required — on the website and app.
• Include these contact details in every response to rights-related communications (access requests, correction requests, erasure requests, grievances).

Rule 10 — Verifiable Consent for Children

The FinEdge Context

FinEdge’s new ‘Junior Finance’ feature allows parents to create savings accounts for children under 18. Before processing any child’s data, FinEdge must obtain verifiable parental consent as prescribed in Rule 10.

What Rule 10 Says

• Rule 10(1): Before processing a child’s data, obtain verifiable parental consent and verify the parent is an identifiable adult:
• Rule 10(1)(a): Verification can use reliable identity/age details already held by the platform (e.g., the parent’s existing verified account).
• Rule 10(1)(b): Or identity/age details voluntarily provided directly, or via a virtual token from an authorised entity (including Digital Locker).
• Rule 10(2): Adult means 18+. Authorised entity includes government-designated entities, entrusted entities, and Digital Locker service providers under the IT Act.

Rule 11 — Verifiable Consent for Persons with Disability

The FinEdge Context

A guardian approaches FinEdge to manage a loan account on behalf of a person with an intellectual disability. FinEdge must verify the guardian’s authority before processing the individual’s data.

What Rule 11 Says

• Rule 11(1): Verify that the lawful guardian is appointed by a court or by a designated authority or local-level committee under applicable guardianship law (e.g., the National Trust Act, 1999 or the Rights of Persons with Disabilities Act, 2016).
• Rule 11(2): Defines the designated authority (appointed under RPwD Act) and relevant guardianship laws, and specifies which persons with disabilities are covered.

Rule 12 — Limited Exemptions for Children’s Data Processing

The FinEdge Context

FinEdge’s partner EdTechPlus operates an educational platform used by schools. Some data processing for children’s safety and educational tracking may qualify for limited exemptions under Rule 12.

What Rule 12 Says

• Rule 12 permits limited exemptions from certain obligations under Section 9 of the DPDPA for specified classes/purposes listed in the Fourth Schedule, subject to strict conditions.

Fourth Schedule — Part A: Classes of Data Fiduciaries Exempt in Specific Situations

• Healthcare establishments/professionals: only for providing health services to the child (necessary for protecting the child’s health).
• Allied healthcare professionals: only to support healthcare treatment/referral plans.
• Educational institutions: only for tracking/behaviour monitoring for education activities or safety of enrolled children.
• Crèches/day care caregivers: only for tracking/behaviour monitoring for children’s safety.
• Transport providers engaged by schools/crèches: only for tracking location during travel for children’s safety.

Fourth Schedule — Part B: Purposes Exempt with Conditions

• To perform legal powers/duties in a child’s interest — only as necessary.
• To provide government subsidy/benefit/service in a child’s interest — only as necessary.
• To create an email account used only for email communication — only as necessary.
• To determine a child’s real-time location for safety/protection/security — only location tracking and only as necessary.
• To ensure harmful content/services/advertisements are not accessible to a child — only as necessary.
• To confirm the user is not a child and to follow due diligence rules — only as necessary.

Rule 13 — Additional Obligations of Significant Data Fiduciary (SDF)

The FinEdge Context

FinEdge has grown rapidly and now has 25 lakh active users, processes over Rs. 500 crore in loans monthly, and uses AI-based risk profiling. The Central Government is assessing whether to notify FinEdge as a Significant Data Fiduciary. If notified, Rule 13 imposes significant additional obligations.

What Rule 13 Says

• Rule 13(1): Annual Data Protection Impact Assessment (DPIA) and audit — every 12 months.
• Rule 13(2): The DPIA/audit professional must submit a report with significant observations to the Data Protection Board.
• Rule 13(3): Due diligence to ensure technical measures and algorithms are not likely to risk Data Principal rights.
• Rule 13(4): For specified categories of data, ensure data and related traffic data is not transferred outside India (data localisation obligation).
• Rule 13(5): A Government committee supports and oversees implementation of this Rule.

Rule 14 — Operationalising Rights of Data Principals

The FinEdge Context

Priya wants to access all personal data FinEdge holds about her. Rahul wants to correct his income data (incorrectly recorded). Vikram wants to erase his account data after closing his loan. Rule 14 prescribes exactly how FinEdge must operationalise these rights.

What Rule 14 Says

• Rule 14(1): Publish the methods to submit rights requests and the identifiers needed to identify the Data Principal.
• Rule 14(2): Data Principal can submit requests using those published methods.
• Rule 14(3): Publish the grievance redressal timeline (maximum 90 days) and implement measures to meet it.
• Rule 14(4): Enable nomination — allow Data Principals to nominate a person to exercise rights in case of death or incapacity (as per applicable law and terms of service).
• Rule 14(5): ‘Identifier’ includes customer ID, application reference number, email address, mobile number, licence number, etc.

Rule 15 — Transfer of Personal Data Outside India

The FinEdge Context

FinEdge uses a US-based cloud analytics vendor to process loan application data and generate risk reports. Cross-border data transfers are common in FinEdge’s ecosystem. Rule 15 governs the conditions for such transfers.

What Rule 15 Says

• Transfer of personal data outside India is permitted, but the Data Fiduciary must comply with any requirements imposed by the Central Government regarding making data available to a foreign State or its agencies/entities.
• The Government can restrict or condition transfers where foreign state access to Indian personal data poses sovereignty, security, or public interest concerns.

Rule 16 — Research, Archiving & Statistical Processing Exemption

The FinEdge Context

FinEdge’s research team wants to analyse historical loan repayment patterns to improve its AI credit model. The research will not be used to make decisions about individual customers. Rule 16 provides a potential exemption from certain DPDPA obligations for such processing.

What Rule 16 Says

• The DPDPA does not apply to processing that is necessary for research, archiving, or statistical purposes, if carried out in accordance with the standards prescribed in the Second Schedule.
• The exemption applies only where the processing is not used to make decisions about specific identifiable individuals.

Rules 17–21 — Data Protection Board: Functioning & Governance

The FinEdge Context

FinEdge has received a complaint from a customer filed with the Data Protection Board. FinEdge’s legal team needs to understand how the Board operates, who makes decisions, and what timelines apply.

Rule 17 — Appointment of Chairperson and Members

• Appointments are made through Search-cum-Selection Committees comprising senior officials and independent experts.
• This ensures the Board operates independently with qualified leadership, insulated from direct government influence in individual decisions.

Rule 18 — Salaries and Terms

• Chairperson: Rs. 4,50,000 per month (no house or car facility).
• Members: Rs. 4,00,000 per month.
• No pension or gratuity for Board service; travel allowances align with senior Central Government officer scales.

Rule 19 — Board Meetings and Procedure

• Quorum for meetings: one-third of Members.
• Conflict of interest requires mandatory abstention.
• Emergency decisions can be taken through circulation.
• Inquiry timeline: 6 months from initiation (with provision for extensions).

Rule 20 — Board as a Digital Office

• The Board operates as a fully digital office using techno-legal measures.
• All proceedings, complaints, notices, and hearings are conducted through digital platforms.

Rule 21 — Board Staff

• Board may appoint staff on deputation from government/statutory/autonomous/public sector bodies for up to 5 years.
• May also engage staff from the National Institute for Smart Government (NISG) with market-guided compensation.

Rule 22 — Appeal to the Appellate Tribunal

The FinEdge Context

FinEdge disagrees with a Board decision imposing a penalty of Rs. 50 lakh for delayed breach notification. FinEdge’s legal team wants to appeal. Rule 22 governs the appeals process.

What Rule 22 Says

• Rule 22(1): Appeals against Board decisions can be filed digitally with the Appellate Tribunal.
• Rule 22(2): Appeal fees are payable digitally (via UPI or RBI-authorised payment systems), similar to TRAI Act appeals.
• Rule 22(3): The Tribunal follows natural justice principles; it is not bound by the Civil Procedure Code (CPC). The Tribunal also functions as a digital office.

Rule 23 — Government Information Requests

The FinEdge Context

The Ministry of Finance contacts FinEdge requesting detailed loan disbursement data for a policy review on digital lending. Separately, the Ministry directs FinEdge not to disclose the information request itself. Rule 23 governs both situations.

What Rule 23 Says

• Rule 23(1): The Central Government can require a Data Fiduciary or intermediary to provide information for Seventh Schedule purposes through an authorised person.
• Rule 23(2): The Government can direct the entity not to disclose the information request or the fact of furnishing if disclosure could harm sovereignty, integrity, or security of India.
• Rule 23(3): ‘Intermediary’ has the same meaning as in the Information Technology Act, 2000.

Seventh Schedule — Authorisation for State Processing

• For sovereignty/integrity of India or security of the State: an officer designated by the Central Government or head of the instrumentality.
• For performing functions under law or disclosing information to meet legal obligations: person authorised under applicable law.
• For assessment to notify a Significant Data Fiduciary: an officer designated by the Secretary, MeitY.

Quick Compliance Checklist: FinEdge’s Rule-by-Rule Readiness

MODULE 3

Story-Based Learning

Electronic Evidence under the Bharatiya Sakshya Adhiniyam, 2023

With Special Reference to Section 63 Certificate & DPDPA Proceedings

Case Study:

TechNova Digital Pvt. Ltd.

Introduction: The TechNova Story

TechNova Digital Pvt. Ltd. is a fast-growing Mumbai-based fintech platform operating a digital lending and payment ecosystem serving over 2 crore users across India. Every interaction on TechNova’s platform is captured electronically:

• Onboarding forms and KYC submissions
• Consent capture timestamps with notice version and IP address
• Loan processing and transaction logs
• Marketing communication logs
• Data sharing records with analytics partners
• Security alerts, firewall and intrusion detection logs
• Breach detection and notification timelines
• Account deletion requests and audit trails
• Grievance tickets with resolution timestamps

One day, TechNova’s compliance team receives a formal notice from the Data Protection Board of India. Mr. Rohan Mehta, a Data Principal and TechNova user, has filed a complaint before the Board alleging four violations:

TechNova’s legal team asserts complete compliance. The Board’s response is decisive:

“Assertions of compliance are insufficient. Compliance must be proved through legally admissible electronic evidence. TechNova must produce its records in accordance with Section 63 of the Bharatiya Sakshya Adhiniyam, 2023.”

This module traces how TechNova must approach each allegation — not merely through internal policies, but through the production of legally admissible electronic evidence with a proper Section 63 certificate. The module is structured around the six elements of the Section 63 certificate, applied to each of TechNova’s four compliance challenges.

Part I — Why Electronic Evidence Matters in DPDPA Proceedings

Compliance Is Not Enough — Proof Is Required

Under the Digital Personal Data Protection Act, 2023, TechNova has invested significantly in compliance infrastructure: a consent management system, a breach notification workflow, a data deletion mechanism, and a grievance redressal portal. But when the Board asks for proof, none of these systems matter unless the records they generate are admissible evidence.

The BSA 2023 defines evidence under Section 2(1)(e) as including:

• Oral evidence: testimony of witnesses.
• Documentary evidence: all documents, including electronic records produced for inspection.

In TechNova’s case, every compliance record is an electronic document — a consent log, a breach report, a deletion audit trail. For these to be admissible, they must satisfy Section 63 of the BSA 2023.

Evolution from Section 65B (IEA) to Section 63 (BSA 2023)

Understanding Section 63 requires tracing its legislative history. The old Indian Evidence Act, 1872 (IEA) had no specific provision for electronic records. Over time, Section 65B was introduced by amendment to govern admissibility of electronic records. Several landmark judgments shaped its interpretation:

Section 63 BSA 2023 — The New Framework

Section 63 of the Bharatiya Sakshya Adhiniyam, 2023 modernises the framework for electronic evidence. It moves beyond the limitations of Section 65B by explicitly covering:

• Computers and computing devices of all types
• Communication devices (smartphones, tablets, IoT devices)
• Network systems (cloud environments, APIs, gateways)
• Intermediary systems (third-party processors, analytics partners)
• Automated systems and AI-generated logs

Most importantly, Section 63 mandates that the certificate include hash values — a cryptographic requirement that was not explicitly in Section 65B. This transforms the certificate from a procedural formality into a technical guarantee of data integrity.

Part II — Anatomy of the Section 63 Certificate

Section 63(4) specifies the mandatory contents of the certificate. This is the most operationally critical part of TechNova’s evidence strategy. The certificate must contain six elements. Each is examined below through the TechNova lens.

Element 1 — Identification of the Record [S.63(4)(a)]

What the Law Requires

The certificate must specifically identify the electronic record being produced. A generic reference to ‘our system logs’ is insufficient.

TechNova’s Application

• Consent Log: “Consent_Log_Rohan_Mehta_UserID_TN-2024-88421_Version2_Notice_Onboarding.csv”
• Data Transfer Record: “Analytics_Partner_DataShare_Log_Q1_2024_Batch_007.json”
• Breach Report: “Breach_Detection_Log_Incident_TN-BR-2024-003_Timeline.pdf”
• Deletion Audit Trail: “Account_Deletion_Audit_Rohan_Mehta_TN-88421_20240315.xml”

Element 2 — Method of Production [S.63(4)(b)]

What the Law Requires

The certificate must explain how the electronic record was produced — the process by which digital data was extracted, converted, and made ready for production.

TechNova’s Application

For Rohan Mehta’s consent log:

• Data was auto-generated by TechNova’s Consent Management System (CMS) at the time of onboarding.
• The CMS records: timestamp (IST), IP address of device, notice version displayed, checkbox state, and user action.
• On 15 March 2024, an authorised database administrator exported the record using a read-only query on the production database.
• The export was saved as a CSV file using TechNova’s evidence export tool (EET v2.3).
• The file was immediately hashed using SHA-256 before any further processing.

Element 3 — System Details [S.63(4)(c)]

What the Law Requires

The certificate must describe the computer or system on which the record was stored or through which it was produced. This establishes the technical foundation for admissibility.

TechNova’s Application

TechNova’s system details for the consent log:

• System Type: Amazon Web Services (AWS) cloud environment
• Database: AWS RDS PostgreSQL 14.2, hosted in Mumbai region (ap-south-1)
• Frontend Application: TechNova Mobile App v6.3.1 (iOS and Android)
• API Gateway: AWS API Gateway, routing consent submissions to CMS
• Backup: Automated daily backups to AWS S3, encrypted with AES-256
• Access Controls: Role-based access; production DB accessible only to DBA team via VPN with MFA

Section 63(3) — Multiple Systems as One Integrated System

A key innovation in Section 63 over Section 65B is the explicit provision in Section 63(3): where an electronic record is produced by multiple interconnected systems (frontend app → API gateway → database → backup server), all these systems are treated as one integrated computer system for purposes of the certificate. TechNova does not need a separate certificate for each component.

Element 4 — Conditions of Admissibility [S.63(2) — Four Mandatory Conditions]

This is the core test of admissibility. Section 63(2) imposes four conditions that must be certified:

Condition A: Regular Use

The computer system must have been in regular use by a person in lawful control of the relevant activities at the time the record was generated.

• TechNova certifies: The CMS has been in continuous operational use since March 2022 for all customer onboarding activities. It is maintained and operated by TechNova’s Technology Operations team under the supervision of the Chief Technology Officer.

Condition B: Ordinary Course of Business

The information was fed into the computer in the ordinary course of relevant activities.

• TechNova certifies: Consent logs are auto-generated by the CMS as a core function of the onboarding process. No manual entry is involved. Every customer onboarding triggers an automatic consent log entry in real time.

Condition C: Proper Operation

The computer was operating properly throughout the relevant period, or if there was a malfunction, it did not affect the record in question.

• TechNova certifies: System uptime logs confirm 99.97% availability during January 2024 (the period when Rohan Mehta’s consent was recorded). No system fault, outage, or error was logged during the specific 14:30–15:00 IST window on 10-January-2024. AWS CloudWatch monitoring logs are annexed.

Condition D: Authentic Reproduction

The copy of the electronic record faithfully reproduces the original record stored in the computer.

• TechNova certifies: The exported CSV file Consent_Log_TN-88421.csv is a direct, unmodified export from the production database. No field has been added, deleted, or altered. The SHA-256 hash of the exported file matches the hash of the original database record as verified by the database administrator.

Element 5 — Hash Value [S.63(4) — Mandatory Cryptographic Requirement]

What is a Hash Value?

A hash value (also called a digital fingerprint) is a unique alphanumeric string generated by applying a cryptographic algorithm (such as SHA-256) to a file. Any change — even a single character — in the file produces a completely different hash value. This makes hash values the gold standard for proving data integrity in digital evidence.

Why Section 63 Mandates Hash Values

Section 65B (old law) did not explicitly require hash values. Courts relied on the certificate signer’s word alone. Section 63 BSA 2023 introduces hash values as a mandatory requirement, transforming the evidentiary framework from trust-based to verification-based.

TechNova’s Hashing Process

• Step 1 — Pre-Extraction Hash: Before extraction, TechNova’s database administrator runs a hash on the specific records within the database. This is the reference hash.
• Step 2 — Extraction: Records are exported using read-only queries via Evidence Export Tool v2.3.
• Step 3 — Post-Extraction Hash: Immediately after extraction, SHA-256 hash is applied to the exported file.
• Step 4 — Hash Comparison: Pre-extraction and post-extraction hashes are compared. They must be identical.
• Step 5 — Hash in Certificate: The post-extraction SHA-256 hash value is recorded verbatim in the Section 63 certificate.
• Step 6 — Board Verification: The Board or its expert can independently run SHA-256 on the produced file and compare with the certificate hash. Any mismatch proves tampering.

TechNova’s Hash Values (Sample)

Element 6 — Signatories to the Certificate [S.63(4)(d)]

Who Can Sign the Section 63 Certificate?

The certificate must be signed by a person occupying a responsible official position in relation to the operation of the relevant computer system. Section 63 also envisages involvement of an expert for technical aspects.

TechNova’s Signing Authority

Part III — Applying Section 63 to Each Allegation Against TechNova

Allegation 1 — Invalid Consent for Marketing Communications

The Dispute

Rohan Mehta alleges that TechNova sent him marketing SMS and email communications without valid consent. He claims the consent was bundled into a general ‘Terms of Service’ acceptance and was not freely given, specific, or informed.

TechNova’s Evidence Strategy

TechNova’s consent management system captures consent at two levels: onboarding consent (for loan processing) and separate marketing consent (opt-in tick box on a dedicated screen). The system records:

• Timestamp of consent action (IST, to the second)
• IP address of the device used
• Version of the privacy notice displayed at the time
• User action: explicit tick of the marketing consent checkbox
• Session ID linking consent to the specific onboarding session
• Confirmation SMS sent to Rohan’s registered mobile number

Section 63 Certificate for Consent Evidence

Allegation 2 — Unauthorised Sharing of Data with Analytics Partner

The Dispute

Rohan Mehta alleges TechNova shared his personal data with an analytics partner, DataSense Analytics Pvt. Ltd., without his knowledge or a separate consent. He contends this violates DPDPA’s consent requirements.

TechNova’s Evidence Strategy

TechNova’s data sharing is governed by its Data Processing Agreement (DPA) with DataSense. The DPA permits sharing of pseudonymised transactional data for fraud detection analysis only. TechNova’s data transfer logs record:

• Every data transfer event with timestamp and batch ID
• Fields transferred (pseudonymised: no PAN, Aadhaar, or name — only transaction amounts, device ID, and behavioural patterns)
• API endpoint used for transfer (DataSense API v3.2)
• Encryption status of the transfer (TLS 1.3)
• Consent basis recorded at time of transfer: Rohan’s consent to ‘fraud detection and security’ under the privacy notice

Section 63 Certificate for Data Transfer Evidence

Allegation 3 — Delayed Breach Notification

The Dispute

Rohan Mehta alleges that TechNova suffered a data breach in February 2024 but failed to notify him promptly as required by DPDPA Rule 7(1). He claims he learnt about the breach from a news article, not from TechNova.

TechNova’s Evidence Strategy

TechNova’s incident response logs record every step of its breach detection and notification process:

• Breach detection timestamp: 14-February-2024, 23:47 IST (AWS Security Hub alert)
• Internal triage completion: 15-February-2024, 02:15 IST
• User notification dispatched: 15-February-2024, 03:30 IST (SMS and email to all 142 affected users, including Rohan Mehta)
• Board initial notification: 15-February-2024, 04:00 IST (via Board’s digital portal)
• Board detailed report: 17-February-2024, 15:00 IST (within 72 hours of detection)
• Notification to Rohan’s registered mobile (+91-9XXXXXXXXX): SMS delivery confirmed by Airtel at 03:31 IST, 15-Feb-2024

Section 63 Certificate for Breach Notification Evidence

Allegation 4 — Failure to Erase Personal Data

The Dispute

Rohan Mehta closed his TechNova account on 15-March-2024. He filed an erasure request on the same date. He alleges that as of the date of his complaint, his personal data had not been erased from TechNova’s systems.

TechNova’s Evidence Strategy

TechNova’s account deletion process triggers a multi-system erasure workflow:

• Erasure request received and logged in the Rights Management System (RMS) at 10:30 IST, 15-March-2024
• 48-hour pre-erasure notice sent to Rohan at 10:31 IST, 15-March-2024 (as required by DPDP Rule 8(2))
• No further login or contact from Rohan during the 48-hour window
• Automated erasure workflow executed at 10:35 IST, 17-March-2024:
• Production database: all personal data fields overwritten with null values
• AWS S3 backup: backup deleted from all 3 replication zones
• Analytics partner DataSense: deletion request sent via API; acknowledgement received at 11:00 IST
• Email server: all communication records purged
• Erasure completion certificate issued automatically by RMS at 10:40 IST, 17-March-2024
• Residual retention: transaction logs retained in anonymised form for statutory requirements (RBI, PMLA) — no personal identifiers retained

Section 63 Certificate for Erasure Evidence

Part IV — What Happens When Section 63 Certificate is Absent or Defective

Consequences of Missing or Defective Certificate

Common Certificate Defects and How to Avoid Them

Part V — Section 63 Certificate: TechNova Template

The following is TechNova’s standard Section 63 BSA 2023 Certificate template, as applied to the consent log in the Rohan Mehta proceedings:

Conclusion

The TechNova case demonstrates the most critical insight of the DPDPA era: compliance must be evidence-ready from day one. It is no longer sufficient to have good processes — those processes must generate admissible electronic evidence that can withstand legal scrutiny before the Data Protection Board.

Section 63 of the Bharatiya Sakshya Adhiniyam, 2023 is the bridge between TechNova’s compliance operations and the legal proceedings it may face. Every consent log, transfer record, breach notification, and erasure audit trail must be:

• Generated systematically in the ordinary course of business
• Stored on systems that are regularly used and properly functioning
• Extracted using documented, traceable, read-only procedures
• Hashed immediately upon extraction using SHA-256
• Certified by the CISO, DPO, and an independent digital forensic expert
• Accompanied by system architecture documentation and uptime logs as annexures

In the DPDPA era, your compliance is only as strong as your Section 63 certificate.

POSSIBLE DISPUTES

Story-Based Learning

Digital Personal Data Protection Act, 2023

All 9 Dispute Categories with Case Studies

SwiftMart E-Commerce Pvt. Ltd. · HealthPlus Insurance Ltd.

Introduction: The SwiftMart Story

SwiftMart E-Commerce Pvt. Ltd. is a Hyderabad-based online marketplace offering consumer electronics, apparel, and grocery delivery across Tier I, II, and III cities in India. With over 12 million registered users, SwiftMart collects and processes significant volumes of personal data to facilitate transactions, personalise recommendations, and optimise logistics.

SwiftMart collects the following personal data from its customers:

• Full name and date of birth
• Mobile number and email address
• Home and delivery addresses
• Payment card details and UPI IDs
• Purchase history and browsing behaviour
• Device identifiers and location data
• Age and parental consent records (for minor users)

This document traces the nine major categories of disputes that can arise under the DPDPA through SwiftMart's journey — from collecting consent, to handling a data breach, to facing an inquiry before the Data Protection Board of India (DPBI). A parallel insurance case study (HealthPlus Insurance Ltd.) is introduced from Category 3 onwards for comparative learning.

Dispute Category 1 — Consent-Related Disputes

Consent lies at the heart of the DPDPA. Under Section 6, consent must be free, specific, informed, unconditional, and unambiguous. Any deviation creates actionable disputes. SwiftMart's onboarding flow presents five potential consent-related dispute scenarios.

Dispute Category 2 — Notice & Transparency Disputes

Section 5 of the DPDPA requires every Data Fiduciary to provide a clear, accessible, and complete notice before or at the time of data collection. Inadequate notice undermines a Data Principal's ability to make an informed decision, and creates disputes that can be raised before the DPBI.

Dispute Category 3 — Data Principal Rights Disputes

Chapter III of the DPDPA (Sections 11–15) confers on every Data Principal a suite of enforceable rights: the right to access, correct, erase, and nominate a representative. Denial of, or failure to respond to, these rights constitutes a separate category of dispute. A parallel case from HealthPlus Insurance Ltd. is introduced below.

Dispute Category 4 — Fiduciary Obligations Disputes

Chapter II of the DPDPA (Sections 4–10) imposes affirmative obligations on Data Fiduciaries — to limit data collection, restrict retention, implement security, and designate grievance mechanisms. Failure to meet these obligations creates enforcement disputes distinct from individual rights claims.

Dispute Category 5 — Data Breach Disputes

Section 8(6) of the DPDPA requires every Data Fiduciary to notify the Data Protection Board and affected Data Principals promptly upon becoming aware of a personal data breach. Delays, non-disclosure, and failure to remediate are separately actionable and attract the highest tier of penalties.

Dispute Category 6 — Children's Data Disputes

Section 9 of the DPDPA imposes heightened obligations when processing personal data of children (under 18 years of age). Verifiable parental consent is mandatory. Behavioural tracking and targeted advertising targeting children is prohibited. These obligations carry the second-highest penalty tier under the Act.

Dispute Category 7 — Cross-Border Transfer Disputes

Section 16 of the DPDPA permits cross-border transfer of personal data only to countries approved by the Central Government. Unapproved transfers, undisclosed transfers, and transfers without adequate safeguards constitute distinct violations. With SwiftMart's reliance on global cloud and analytics vendors, this is a commercially critical area of compliance.

Dispute Category 8 — Significant Data Fiduciary (SDF) Disputes

Section 10 of the DPDPA empowers the Central Government to classify certain Data Fiduciaries as Significant Data Fiduciaries (SDFs) based on the volume and sensitivity of data processed, risk to Data Principals, and national security considerations. SDFs face heightened obligations — including a mandatory Data Protection Officer (DPO), periodic Data Protection Impact Assessments (DPIAs), and algorithmic accountability. If SwiftMart is classified as an SDF, these obligations activate immediately.

Dispute Category 9 — Grievance & Enforcement Disputes

The DPDPA's enforcement architecture — the Data Protection Board of India (DPBI), the appellate mechanism before TDSAT, and the alternative dispute resolution pathway — creates a structured environment for resolving disputes between Data Principals and Data Fiduciaries. Procedural violations within this enforcement framework are themselves independently actionable.

Penalty Scale Under DPDPA 2023

The following penalty tiers apply to the dispute categories covered in this document. Penalties are imposed by the Data Protection Board of India after inquiry and are subject to appeal before TDSAT.

Integrated Enforcement Scenario: The Full SwiftMart Arc

The following sequence demonstrates how disputes across multiple categories can compound into a comprehensive enforcement action:

• SwiftMart collects data with bundled consent and an English-only privacy notice (Categories 1 & 2).
• Customer Meera Nair discovers her address is being shared with a real estate advertiser and requests erasure — SwiftMart ignores her request (Category 3).
• An unencrypted S3 bucket exposes 900,000 customer payment records — SwiftMart delays notification for 34 days (Category 5).
• It emerges that SwiftMart Junior profiles were being behaviorally tracked — violating Section 9 (Category 6).
• As an SDF, SwiftMart's face-scan feature was deployed without a DPIA (Category 8).
• The DPBI issues a comprehensive enforcement order — SwiftMart fails to comply within 60 days (Category 9).
• The Board advises the Government that platform access restriction is in the public interest. SwiftMart's app is blocked pending compliance.

This sequence demonstrates that DPDPA violations are rarely isolated. A consent failure at onboarding, left unaddressed, cascades into rights violations, breach disputes, and ultimately platform-level sanctions. The cost of non-compliance compounds with every category left unaddressed.

Consolidated Summary: Possible Disputes at a Glance

Final Conceptual Takeaway

Disputes under the DPDPA do not arise only from dramatic breaches or overt non-compliance. They arise from design choices made at product inception — when forms are built, consent flows are architected, and vendor contracts are signed. The most consequential compliance failures are embedded long before any individual customer complaint is filed.

Through the SwiftMart and HealthPlus stories, this document has traced the full landscape of possible disputes — from the smallest consent form deficiency to platform-level enforcement action. The DPDPA creates accountability not for breaches alone, but for every instance where a Data Principal's autonomy over their own data is compromised.

Understanding the complete dispute landscape is not merely a legal exercise. It is a governance imperative for every organisation that processes personal data of individuals in India.

Disclaimer: For educational and awareness purposes only. Not legal advice. Consult a qualified data protection lawyer for specific matters. | DPDPA 2023 · India