Section 11 - Right to access information about personal data

1.1 Detailed clause-by-clause commentary read with Rule 14 of the DPDP Rules, 2025

Key point

1.2 Statutory structure

Key point

Section 11 creates a right to obtain information from a Data Fiduciary to whom the Data Principal has previously given consent, including the consent contemplated in Section 7(a).

1.3 Subject to the conditions in the section, the Data Principal may obtain:

1. a summary of the personal data currently being processed;

2. a summary of the processing activities undertaken in respect of that personal data;

3. the identities of other Data Fiduciaries and Data Processors with whom the personal data has been shared;

4. a description of the personal data shared with each such recipient; and

5. any additional prescribed information.

Key point

Section 11(2) creates a limited law-enforcement and cyber-incident qualification. It removes the disclosure obligations in Section 11(1)(b) and Section 11(1)(c) where personal data was shared:

• with another Data Fiduciary;

• that Data Fiduciary was authorised by law to obtain it;

• the sharing followed a written request; and

• the request was for one of the purposes expressly listed in subsection (2).

Key point

The subsection does not remove the Data Principal’s right under Section 11(1)(a) to obtain a summary of the personal data being processed and the processing activities undertaken by the original Data Fiduciary.

2. “The Data Principal shall have the right”

2.1 The opening words create an entitlement belonging to the Data Principal.

Key point

A Data Principal is the individual to whom the personal data relates. In the case of a child, the definition includes the child’s parent or lawful guardian. In the case of a person with disability, it includes the lawful guardian acting on the person’s behalf.

2.2 The right therefore ordinarily belongs to:

• the individual adult whose personal data is processed;

• the parent or lawful guardian in the case of a child;

• the lawful guardian acting for a qualifying person with disability;

• a nominee, in circumstances governed by Section 14 and Rule 14.

2.3 The right is not dependent on proving that:

• a breach has occurred;

• the Data Fiduciary has acted unlawfully;

• the Data Principal has suffered loss;

• the Data Principal intends to withdraw consent;

• litigation is contemplated.

Key point

A Data Principal may exercise Section 11 simply to understand what personal data is being processed, what the Data Fiduciary is doing with it and with whom it has been shared.

3. The right is informational

4. Section 11 is principally a right to information. It does not itself grant:

• correction;

• completion;

• updating;

• erasure;

• compensation;

• transfer of personal data to another provider;

• objection to processing;

• restriction of processing.

Correction and erasure are dealt with in Section 12. Grievance redressal is addressed in Section 13. Nomination is addressed in Section 14.

4.1 Information obtained through Section 11 may enable the Data Principal to exercise those other rights. For example:

• a summary may reveal inaccurate information, leading to a correction request;

• the recipient list may reveal an unexpected disclosure, leading to a grievance;

• the processing summary may reveal that a purpose has ended, leading to an erasure request;

• the identity of a processor may allow the Data Principal to understand how the service is delivered.

5. Section 11 is therefore an enabling right. It gives the Data Principal information needed to assess the processing relationship.

6. “To obtain from the Data Fiduciary”

6.1 The duty to respond rests on the Data Fiduciary.

Key point

The Data Fiduciary is the person who, alone or together with another person, determines the purpose and means of processing personal data. A Data Processor, by contrast, processes personal data on behalf of the Data Fiduciary.

6.2 A Data Principal ordinarily directs the Section 11 request to the Data Fiduciary, not separately to each Data Processor.

6.3 This allocation is consistent with Section 8(1), under which the Data Fiduciary remains responsible for processing undertaken:

• by itself; and

• on its behalf by a Data Processor.

6.4 The Data Fiduciary cannot refuse to answer by stating that the requested information is stored by:

• a cloud provider;

• payroll provider;

• marketing vendor;

• recruitment platform;

• CCTV storage provider;

• AI service provider;

• group service company.

Key point

If the processing is undertaken on behalf of the Data Fiduciary, the Data Fiduciary must have sufficient contractual and operational arrangements to obtain the information needed for its response.

7. Processor assistance

Key point

Section 11 does not directly prescribe a processor-assistance obligation. Section 8(2), however, requires processing by a processor to occur under a valid contract, and Section 8(1) leaves responsibility with the Data Fiduciary.

7.1 A Data Fiduciary should therefore ensure operationally that its processor arrangements allow it to determine:

• what personal data the processor holds;

• what processing activities it undertakes;

• what data was shared with it;

• whether the processor uses subprocessors;

• whether data has been erased;

• whether the processor can search data relating to the requesting Data Principal.

Key point

A Data Fiduciary cannot rely on a processor architecture that makes the Data Fiduciary unable to exercise the control necessary to comply with Section 11.

8. Separate Data Fiduciaries

Where information has been disclosed to another Data Fiduciary, the recipient independently determines its processing purpose or means.

Section 11(1)(b) requires the original Data Fiduciary to identify that recipient and describe the personal data shared, subject to Section 11(2).

Key point

The original Data Fiduciary is not necessarily required to provide a complete description of every processing activity subsequently undertaken independently by the recipient. The text requires:

• the identity of the recipient; and

• a description of the personal data shared by the original Data Fiduciary.

Key point

If the Data Principal wants information about the recipient’s own processing, a separate request may need to be made to that recipient, provided the statutory conditions for exercising Section 11 against it are satisfied.

9. “To whom she has previously given consent”

9.1 This phrase limits the Data Fiduciaries against whom the Section 11 right may be exercised.

Key point

The right is not drafted as a generally applicable access right against every person who happens to process the Data Principal’s personal data. It applies to the Data Fiduciary to whom the Data Principal has previously given consent for processing.

9.2 The wording therefore raises an important scope issue for processing under Section 7.

10. Consent under Section 6

10.1 The clearest application is where the Data Principal gave consent satisfying Section 6.

10.2 Examples include:

• a customer consenting to account creation;

• a user agreeing to receive a digital service;

• a guest consenting to an optional loyalty programme;

• an applicant consenting to future talent-pool retention;

• a person consenting to an optional marketing activity.

10.3 The Data Principal may request Section 11 information from the Data Fiduciary that obtained that consent.

11. Section 7(a)

12. Section 11 expressly adds:

12.1 “including consent as referred to in clause (a) of section 7.”

Key point

Section 7(a) permits processing for the specified purpose for which the Data Principal voluntarily provided personal data to the Data Fiduciary and in respect of which she has not indicated that she does not consent to its use.

12.2 This means the Section 11 right is not confined to a formally documented Section 6 consent flow.

12.3 It also extends to the relationship contemplated in Section 7(a), where:

• the Data Principal voluntarily provides personal data;

• she provides it for a specified purpose;

• she has not indicated non-consent to its use for that purpose.

12.4 Example: Pharmacy receipt

12.5 An individual gives a pharmacy her mobile number and asks to receive a payment receipt by message.

Key point

Even if the processing is treated under Section 7(a), the express wording of Section 11 allows the individual to seek information from the pharmacy concerning the relevant personal-data processing.

12.6 Example: Real-estate broker

12.7 An individual sends her contact details, budget and accommodation preferences to a broker to find rented accommodation.

The broker processes the information under Section 7(a). The individual can request the information contemplated by Section 11 from the broker.

13. The use of “consent” in relation to Section 7(a)

Key point

Section 7(a) is classified by the Act as a “certain legitimate use,” rather than consent under Section 6. Section 11 nevertheless refers to “consent as referred to in clause (a) of section 7.”

Key point

This wording should be understood as expressly bringing the Section 7(a) relationship within Section 11, even though Section 7(a) is not technically a Section 6 consent ground.

The provision should not be read as converting every Section 7 legitimate use into consent. Its extension is expressly tied to Section 7(a).

14. Processing on other Section 7 grounds

15. Section 11 does not expressly extend the right to every form of processing under Section 7.

15.1 The remaining Section 7 grounds include:

• prescribed State benefits and services;

• State functions;

• legal disclosure to the State;

• judgments and orders;

• medical emergencies;

• public-health threats;

• disasters;

• employment.

15.2 The text of Section 11 does not say:

“The Data Principal shall have the right to obtain information from every Data Fiduciary processing her personal data under Section 7.”

15.3 Instead, it expressly refers to a Data Fiduciary to whom consent was previously given, including the Section 7(a) situation.

15.4 This creates a significant statutory limitation.

16. Employment processing

16.1 An employer may process employee personal data under Section 7(i), including for:

• payroll;

• attendance;

• employment administration;

• protection from loss or liability;

• employee benefits.

Key point

If the employee has never given the employer consent for any relevant processing, the literal wording of Section 11 creates doubt about whether the employee may use Section 11 to obtain access information concerning processing based solely on Section 7(i).

16.2 The Act does not expressly resolve that doubt.

It would therefore be inaccurate to state without qualification that Section 11 grants a universal access right over all employment processing.

17. Medical emergencies

17.1 A hospital may process the personal data of an unconscious patient under Section 7(f).

Key point

The patient may not have previously given the hospital consent. Again, Section 11’s opening condition may not be satisfied on a strictly textual reading.

17.2 Other legal, medical-record or grievance rights may still apply, but Section 11 itself is tied to prior consent or Section 7(a).

18. State and law-enforcement processing

18.1 The State may process information under Section 7(b) or 7(c) without the Data Principal’s consent.

Key point

Section 11 does not expressly grant an access right in respect of all such processing. Section 11(2) further limits disclosure concerning specified written law-enforcement and cyber-incident requests.

18.2 The section therefore does not operate as a general freedom-of-information right against the State.

19. Does prior consent open access to all processing by that Data Fiduciary?

Key point

A more difficult question arises where the Data Principal has given some consent to a Data Fiduciary, but the same Data Fiduciary also processes other personal data under Section 7.

19.1 Consider an employee who:

• has payroll data processed under Section 7(i); and

• separately consents to appearing in a company promotional video.

Key point

The employee has “previously given consent” to the employer. Does that fact permit a Section 11 request covering all personal data being processed by the employer, including payroll and attendance information, or only the processing connected with the consented promotional purpose?

19.2 Two interpretations are possible.

20. Processing-basis-specific interpretation

Key point

Under a narrower interpretation, Section 11 applies only to personal data processed on the basis of the consent previously given, including the Section 7(a) relationship.

20.1 This interpretation draws support from the words:

20.2 “to whom she has previously given consent... for processing of personal data.”

20.3 On this reading, the consent defines the processing relationship to which the access right attaches.

The employee could obtain information concerning the promotional processing but not necessarily payroll processing resting solely on Section 7(i).

21. Data-Fiduciary-level interpretation

21.1 A broader interpretation focuses on the definition of “the said Data Fiduciary.”

21.2 Once the Data Principal has previously given consent to that Data Fiduciary, Section 11(1)(a) refers broadly to:

21.3 “personal data which is being processed by such Data Fiduciary.”

21.4 It does not expressly say “personal data being processed on the basis of that consent.”

Key point

On this reading, prior consent identifies the Data Fiduciary against whom the right may be exercised, after which the response covers all of the Data Principal’s personal data currently being processed by that Data Fiduciary.

22. The unresolved position

22.1 The wording leaves genuine ambiguity.

Key point

The narrower interpretation gives stronger effect to the prior-consent condition. The broader interpretation gives stronger effect to the unqualified reference to personal data “being processed by such Data Fiduciary.”

22.2 Until the Data Protection Board or courts clarify the issue, a Data Fiduciary should:

• identify the basis used for each processing activity;

• avoid representing Section 11 as an unlimited access right without qualification;

• consider whether a broader response can be provided consistently with law, security and third-party rights;

• document the interpretation applied.

The Act does not authorise a Data Fiduciary to manipulate this ambiguity by obtaining trivial consent solely to narrow or avoid rights.

23. “Upon making to it a request”

23.1 The right is exercised through a request.

23.2 The Data Fiduciary is not required by Section 11 to provide this information automatically at fixed intervals.

23.3 The Data Principal must initiate the process.

23.4 The request must be made:

• to the relevant Data Fiduciary;

• through the means published by it;

• using the particulars required to identify the Data Principal under its terms of service.

24. Rule 14 supplies the procedural framework.

25. No requirement to give reasons

26. Section 11 does not require the Data Principal to explain:

• why she wants the information;

• whether she suspects wrongdoing;

• whether litigation is contemplated;

• whether she intends to withdraw consent;

• whether she plans to complain.

A Data Fiduciary should not require justification where the statutory request and identification requirements are otherwise satisfied.

27. Form of request

Rule 14 requires the Data Fiduciary and, where applicable, the Consent Manager to prominently publish on the website, application or both:

• the means through which a request may be made; and

• the particulars required to identify the Data Principal.

27.1 The permissible means may include:

• online form;

• account interface;

• email;

• application feature;

• privacy portal;

• another published mechanism.

27.2 The Rule does not prescribe one universal channel.

27.3 The Data Fiduciary should not force Data Principals to discover an unpublished or obscure internal route.

28. Rule 14(1): Prominent publication of the request mechanism

29. Rule 14 requires the request means to be prominently published.

29.1 A rights mechanism should therefore be reasonably visible on the Data Fiduciary’s website or application.

29.2 A mechanism may not be prominent where it is:

• buried inside lengthy terms;

• available only after several unrelated screens;

• described in unclear language;

• accessible only through general customer support;

• hidden from users without an active account.

Key point

The Rule does not prescribe exact placement, font size or interface layout. The legal requirement concerns prominence and practical discoverability.

30. Data Fiduciary and Consent Manager

Key point

Where applicable, both the Data Fiduciary and Consent Manager must publish the required information concerning means and identification particulars.

Key point

A Consent Manager may assist the Data Principal with the exercise of rights where the legal and technical framework permits. The substantive Section 11 response remains concerned with information held or controlled by the relevant Data Fiduciary.

31. Rule 14 identification particulars

31.1 The Data Fiduciary may require particulars to identify the requester under its terms of service.

Rule 14 defines an identifier broadly. It includes a sequence of characters issued by the Data Fiduciary to identify the Data Principal, such as:

• customer identification file number;

• customer acquisition form number;

• application reference number;

• enrolment ID;

• email address;

• mobile number;

• licence number.

31.2 The list is inclusive rather than exhaustive.

32. Purpose of identification

32.1 Identification serves two purposes:

1. locating the correct personal data; and

2. preventing disclosure to an unauthorised person.

A Section 11 response may itself contain significant personal data. Inadequate identity verification could create a personal data breach.

33. Proportionality of identification

Key point

The Act and Rule permit the Data Fiduciary to require identification particulars. They do not expressly authorise collection of unlimited identity information.

33.1 The Data Fiduciary should use the particulars reasonably required to identify the Data Principal.

Key point

For example, where an authenticated user submits the request from an existing account, demanding an additional complete identity document may be unnecessary unless a genuine risk requires it.

Where the requester has lost account access or the information includes highly consequential data, stronger verification may be justified.

33.2 The Data Fiduciary should not use the verification process to:

• discourage rights requests;

• collect unrelated identity data;

• force submission of Aadhaar where not legally required;

• create unnecessary new profiles.

34. Requests involving children and lawful guardians

Key point

Because the statutory definition of Data Principal includes the parent or lawful guardian in the relevant circumstances, the Data Fiduciary may need to establish:

• identity of the requesting adult;

• relationship or lawful authority;

• whether the request concerns the correct child;

• whether the guardianship remains valid.

34.1 The verification mechanism should align with the child and guardian framework under Rules 10 and 11 where applicable.

35. Rule 14(2): Request to the Data Fiduciary to whom consent was given

36. Rule 14(2) closely follows the statutory limitation in Section 11.

Key point

It provides that the Data Principal may make a request to the Data Fiduciary to whom she has previously given consent, using the published means and furnishing the required particulars.

37. Rule 14 does not enlarge the right into a request against every Data Fiduciary processing the person’s data.

37.1 It also does not independently list the substantive information that must be supplied. The content comes from Section 11.

38. Section 11(1)(a): “A summary of personal data”

38.1 The first substantive entitlement is to:

38.2 “a summary of personal data which is being processed.”

38.3 The word “summary” is critical.

39. Section 11 does not expressly require the Data Fiduciary to provide:

• an exact copy of every record;

• every database row;

• every internal document;

• every email;

• raw source files;

• model source code;

• complete system logs;

• a machine-readable export;

• data portability.

39.1 The right is to a summary.

40. What a meaningful summary should contain

40.1 A meaningful summary should allow the Data Principal to understand the personal data being processed.

40.2 Depending on the context, it may identify categories and representative content such as:

• account and contact information;

• transaction information;

• location information;

• preferences;

• device information;

• communications;

• photographs;

• employment records;

• inferred profiles;

• identity-verification information.

40.3 A response that says only:

40.4 “We process your personal data”

40.5 would not meaningfully summarise the data.

Key point

Equally, the Data Fiduciary is not necessarily required to reproduce every individual event where an intelligible category-level summary accurately explains the information.

41. Category-level versus field-level information

41.1 Whether a category-level response is sufficient depends on precision.

41.2 “Account data” may be too vague.

41.3 “Name, account identifier, registered mobile number, email address and delivery addresses” provides a meaningful summary.

41.4 “Usage information” may be too broad.

41.5 “Login dates, device type, pages viewed and search queries associated with the account” is more informative.

41.6 The requirement is satisfied by substance, not by the label “summary.”

42. Inferred and generated data

42.1 Personal data is not limited to information directly provided by the Data Principal.

If the Data Fiduciary processes an inference or score relating to an identifiable individual, it may form part of the personal data summary.

42.2 Examples include:

• fraud-risk category;

• customer segment;

• predicted preference;

• employee-performance score;

• eligibility classification;

• inferred interest.

Key point

The Data Fiduciary need not necessarily disclose the complete algorithm or model source code. It should not omit the existence of personal data merely because the information was generated internally.

43. “Which is being processed”

Key point

The present-tense wording limits Section 11(1)(a) to personal data currently being processed by the Data Fiduciary when it responds to the request.

The provision does not expressly require a complete history of every item the Data Fiduciary previously processed and lawfully erased.

44. Current processing

44.1 The summary should include personal data that is currently:

• stored;

• used;

• organised;

• retrieved;

• shared;

• analysed;

• otherwise processed.

Data held in an archive or restricted legal-retention environment may still be “being processed” because storage itself falls within processing.

Key point

A Data Fiduciary should not exclude information merely because it is no longer used in daily operations if it remains stored and capable of retrieval.

45. Erased data

45.1 If personal data has been securely erased before the request, Section 11 does not require the Data Fiduciary to reconstruct it.

45.2 The Data Fiduciary should not retain data longer than necessary merely to prepare for a possible future access request.

Key point

Section 11 must therefore be read consistently with Section 8(7), which requires erasure after withdrawal or purpose completion, subject to legal retention.

46. Backups

46.1 Personal data held in backups may still technically be processed through storage.

46.2 The practical response may depend on:

• whether the backup is searchable;

• whether it is used only for recovery;

• whether the SDF or Data Fiduciary can associate data with the requester;

• whether the information is already represented in the active-system summary.

Key point

Section 11 does not expressly prescribe a backup-search standard. A Data Fiduciary should not make a false statement that no data exists where identifiable personal data remains under its control.

47. “Processing activities undertaken”

48. Section 11(1)(a) also requires a summary of the processing activities undertaken with respect to the personal data.

48.1 The response should explain what the Data Fiduciary does with the information.

48.2 Processing activities may include:

• collection;

• storage;

• organisation;

• use;

• analysis;

• transmission;

• sharing;

• updating;

• erasure;

• profiling or inference;

• account administration;

• service delivery;

• security monitoring.

Key point

The summary need not reproduce the organisation’s complete internal technical architecture. It should enable the Data Principal to understand the principal operations performed on her personal data.

49. Purpose and activity are related but distinct

49.1 The purpose explains why the processing occurs.

49.2 The processing activity explains what is done.

49.3 For example:

• purpose: delivery of an order;

• activities: collect address, transmit it to the logistics provider, store delivery confirmation and update order status.

49.4 A response limited to a broad purpose such as “providing services” may not adequately summarise the processing activities.

50. Automated and algorithmic processing

50.1 Where the Data Fiduciary uses personal data in an automated system, the activity should be described accurately.

50.2 For example:

• transaction information analysed for fraud detection;

• application information scored for eligibility;

• viewing history used to recommend content;

• attendance data used to generate reports.

51. Section 11 does not expressly require:

• disclosure of source code;

• disclosure of model weights;

• a detailed explanation of algorithmic logic;

• a general right to human review.

Key point

The processing activity should nevertheless not be concealed behind vague wording such as “analytics” where the system is used to make consequential classifications.

52. Format of the Section 11(1)(a) response

52.1 The Act does not prescribe a mandatory response format.

52.2 A Data Fiduciary may provide the summary through:

• an account dashboard;

• a downloadable document;

• a secure electronic message;

• another intelligible format.

52.3 The response should be:

• connected with the correct Data Principal;

• sufficiently clear;

• secure;

• responsive to the request.

52.4 The Act does not expressly create a right to receive information in a machine-readable or portable format.

Key point

A Data Fiduciary may voluntarily provide richer data-download functionality, but Section 11 should not be described as a statutory data-portability right.

53. Section 11(1)(b): Identities of all other Data Fiduciaries and Data Processors

53.1 The Data Fiduciary must provide:

53.2 “the identities of all other Data Fiduciaries and Data Processors with whom the personal data has been shared.”

53.3 The provision covers two types of recipients:

1. other Data Fiduciaries; and

2. Data Processors.

53.4 This distinction matters because the recipients perform different roles.

54. Other Data Fiduciaries

54.1 Another Data Fiduciary determines its own purpose and means, alone or with another person.

54.2 Examples may include:

• an insurer processing a claim for its own insurance function;

• a bank receiving information for its own regulated operations;

• a government authority processing data for its statutory function;

• a separate company receiving information for its own service.

55. Data Processors

55.1 A Data Processor processes personal data on behalf of the Data Fiduciary.

55.2 Examples may include:

• cloud hosting provider;

• payroll service;

• customer-support vendor;

• messaging service;

• storage provider;

• document-management provider.

Key point

The Data Fiduciary must correctly identify recipient roles. It should not classify every recipient as a processor merely because a contract uses that label.

56. Meaning of “identities”

56.1 The response must identify the recipient, not merely the type of recipient.

56.2 A statement such as:

56.3 “We share data with service providers and business partners”

56.4 does not provide the identities of all other Data Fiduciaries and Data Processors.

56.5 A meaningful identity would ordinarily include the recipient’s legal or recognisable organisational name.

56.6 The Act does not expressly require the response to provide:

• registered address;

• corporate identification number;

• contact details;

• privacy-policy URL;

• country;

• subprocessor contract.

56.7 Those details may be helpful, but the express requirement is identity.

57. Brand name versus legal name

Key point

Where the recipient trades under a brand different from its legal name, the response should identify it in a manner that enables the Data Principal to understand who received the information.

57.1 For example:

57.2 “XYZ Cloud Services India Private Limited, operating the XYZ Cloud service.”

57.3 This is more meaningful than an obscure legal entity name without context.

58. “All other”

58.1 The word “all” does not create an express materiality threshold.

58.2 A Data Fiduciary should not omit a recipient merely because:

• the disclosure was brief;

• only one data field was shared;

• the recipient is an affiliate;

• the processor is considered low risk;

• the sharing occurred through an automated interface.

58.3 The recipient must fall within the scope of personal data shared by the Data Fiduciary.

59. Direct recipients and subprocessors

Section 11(1)(b) refers to Data Fiduciaries and Data Processors “with whom the personal data has been shared by such Data Fiduciary.”

59.1 This raises a question concerning subprocessors.

Key point

If the Data Fiduciary shares data with Processor A, and Processor A independently appoints Subprocessor B under the permitted processing chain, was the data shared with B “by such Data Fiduciary”?

60. Narrow interpretation

60.1 Under a narrow reading, the duty covers recipients to whom the Data Fiduciary directly shared the data.

60.2 The Data Fiduciary shared with Processor A. Processor A then shared with B.

61. Broader on-behalf-of interpretation

Key point

Under a broader reading, Processor A acts on behalf of the Data Fiduciary. The subprocessor chain remains processing undertaken on the Data Fiduciary’s behalf under Section 8(1).

Key point

The Data Fiduciary normally authorises or controls the chain through its processor contract. It may therefore be appropriate to identify downstream processors that actually receive the Data Principal’s data.

62. Unresolved position

63. Section 11 does not expressly use the word “subprocessor.”

63.1 A Data Fiduciary should therefore:

• maintain visibility over the processor chain;

• distinguish recipients that actually received the requesting individual’s data from providers merely available in a general vendor list;

• avoid claiming that no disclosure occurred merely because a processor technically initiated the onward transfer.

63.2 A generic list of every vendor globally may not answer which entities received the particular Data Principal’s data.

64. Affiliates and group companies

64.1 A group company is not exempt from Section 11(1)(b).

64.2 If personal data is shared with an affiliate, its identity should be disclosed where it acts as:

• another Data Fiduciary; or

• a Data Processor.

64.3 The phrase “within our group” is not an identity.

64.4 The response should distinguish:

• the affiliate’s name;

• its role;

• the personal data shared.

64.5 Common infrastructure does not eliminate separate legal personality or factual role analysis.

65. “With whom the personal data has been shared”

65.1 The past-tense phrase may extend beyond recipients that currently hold the data.

The section asks which recipients the personal data has been shared with. It does not expressly say “is currently being shared with.”

65.2 This creates a temporal difference between paragraphs (a) and (b):

• paragraph (a) concerns personal data currently being processed;

• paragraph (b) concerns recipients with whom personal data has been shared.

66. Section 11 does not prescribe the historical period that paragraph (b) must cover.

Key point

A reasonable response should be tied to sharing concerning the personal data within the scope of the request and records retained by the Data Fiduciary.

Key point

The Data Fiduciary is not expressly required to recreate sharing events after all relevant records have been lawfully erased. However, Rule 6 and Rule 8 may independently require the retention of certain logs for prescribed periods.

67. Description of personal data shared

67.1 The Data Fiduciary must provide, along with each recipient’s identity:

67.2 “a description of the personal data so shared.”

67.3 The response should therefore connect the recipient with the information disclosed.

67.4 An adequate response might state:

• delivery provider: name, contact number, delivery address and order reference;

• cloud provider: account information and transaction records stored on behalf of the Data Fiduciary;

• insurer: employee and dependent enrolment details;

• messaging provider: mobile number and message content required for delivery.

67.5 A recipient list without data descriptions is incomplete.

Similarly, a combined statement that “all recipients may receive all collected data” may be inaccurate and insufficiently informative.

68. Description, not necessarily exact copy

68.1 The statute requires a description of the personal data shared. It does not require reproduction of every file or transfer.

68.2 The description should nevertheless be precise enough to explain what moved.

68.3 “Relevant personal data” is too vague unless the context makes the fields clear.

69. Purpose of sharing

70. Section 11(1)(b) does not expressly require the purpose of sharing.

The Data Fiduciary may include it for clarity, and the purpose may also form part of the processing-activity summary under paragraph (a).

70.1 It should not be stated that paragraph (b) independently requires:

• purpose;

• date;

• location;

• transfer mechanism;

• legal ground;

70.2 unless additional information is prescribed under paragraph (c).

71. Section 11(1)(c): Prescribed additional information

71.1 Paragraph (c) permits the Data Principal to obtain:

71.2 “any other information related to the personal data... and its processing, as may be prescribed.”

71.3 This is an enabling provision. It allows the Rules to add information categories.

71.4 The phrase does not itself give the Data Principal a right to demand any information she considers related to processing.

71.5 The additional information must be prescribed.

71.6 Examples that should not be automatically claimed under paragraph (c) without prescription include:

• source code;

• algorithmic logic;

• internal legal advice;

• audit reports;

• complete security architecture;

• trade secrets;

• internal employee communications.

Key point

Rule 14, as reproduced in the final Rules, prescribes the means for exercising rights, identifiers, grievance timelines and nomination procedures. It does not add a substantive category of information specifically under Section 11(1)(c).

Key point

Accordingly, the present substantive Section 11 response rests primarily on paragraphs (a) and (b), unless another applicable rule or later amendment prescribes further information.

72. Section 11(2): Nature of the limitation

Section 11(2) provides that paragraphs (b) and (c) do not apply to certain sharing undertaken for offence or cyber-incident purposes.

72.1 The subsection must be applied according to each of its elements.

72.2 It is not a general exemption for:

• every disclosure to government;

• every police request;

• every internal investigation;

• every fraud inquiry;

• every legal claim;

• every cyber-security vendor.

72.3 The sharing must satisfy the cumulative conditions in subsection (2).

73. First condition: Sharing with “any other Data Fiduciary”

73.1 The recipient must be another Data Fiduciary.

73.2 The subsection does not expressly refer to a Data Processor.

Key point

This is logical because the recipient must be authorised by law to obtain the personal data for its own law-enforcement, cyber-incident, prosecution or punishment-related function.

Key point

A private forensic vendor acting only on the original Data Fiduciary’s instructions is not automatically covered merely because it assists an investigation. Its identity as a processor remains within Section 11(1)(b), unless another legal provision applies.

73.3 The recipient’s role must be determined factually.

74. Second condition: “Authorised by law to obtain such personal data”

74.1 The recipient must possess legal authority to obtain the personal data.

74.2 An informal desire for information is insufficient.

74.3 The original Data Fiduciary should determine whether the requesting recipient is legally authorised to obtain:

• the relevant personal data;

• for the relevant purpose;

• through the relevant procedure.

75. Section 11(2) does not itself create the authority. The authority must come from another law.

Key point

The existence of a government email address or police designation does not necessarily establish legal authority for every category of requested information.

76. Third condition: Written request

76.1 The sharing must be pursuant to:

76.2 “a request made in writing.”

76.3 An oral request does not satisfy the express condition.

Key point

The writing may potentially be physical or electronic, depending on applicable law and procedure, but the requirement is that a written request exists.

76.4 The original Data Fiduciary should retain sufficient evidence of:

• the request;

• requesting authority;

• date;

• scope;

• legal authority;

• stated statutory purpose.

Key point

The section does not prescribe a particular warrant, court order or standard form in every case. Those requirements depend on the law authorising the recipient to obtain the information.

77. Fourth condition: Enumerated purposes

77.1 The written request must be for one or more of these purposes:

• prevention of offences;

• detection of offences;

• investigation of offences;

• prevention of cyber incidents;

• detection of cyber incidents;

• investigation of cyber incidents;

• prosecution of offences;

• punishment of offences.

77.2 The list should be applied according to its terms.

78. Offences

78.1 The request must concern an offence, not merely:

• breach of contract;

• commercial dispute;

• internal policy violation;

• civil claim;

• reputation issue.

79. Cyber incidents

79.1 The subsection separately recognises cyber incidents.

79.2 A legally authorised Data Fiduciary may seek personal data to prevent, detect or investigate such an incident.

79.3 The Act does not define “cyber incident” in Section 11. Its meaning may need to be determined through applicable Indian cyber law.

80. Prosecution and punishment

80.1 The subsection extends beyond investigation to sharing for prosecution or punishment of offences.

80.2 This may include an authorised recipient obtaining information after the investigative stage.

81. Effect of Section 11(2)

81.1 Where all subsection (2) conditions are satisfied, the original Data Fiduciary is not required under:

• Section 11(1)(b) to identify that recipient and describe the data shared; or

• Section 11(1)(c) to provide prescribed further information concerning that sharing.

81.2 The provision protects against disclosure that might:

• reveal an investigation;

• compromise prevention or detection;

• prejudice prosecution;

• disclose an authorised cyber-incident inquiry.

The Act does not require the original Data Fiduciary to tell the Data Principal that information has been omitted under Section 11(2).

Key point

Nor does Section 11(2) expressly prohibit the Data Fiduciary from making any disclosure where another law permits it. The effect is that the statutory Section 11(1)(b) and (c) obligations do not apply.

81.3 The controlling law authorising the recipient may independently require confidentiality.

82. Section 11(2) does not remove Section 11(1)(a)

82.1 The subsection expressly refers only to clauses (b) and (c).

82.2 It does not disapply clause (a).

82.3 The Data Principal therefore retains the right, subject to the opening conditions in Section 11(1), to obtain:

• a summary of personal data currently being processed by the original Data Fiduciary; and

• a summary of the processing activities undertaken by that Data Fiduciary.

Key point

The response under paragraph (a) should not be used indirectly to reveal information that another applicable law requires to remain confidential. At the same time, the Data Fiduciary should not rely on Section 11(2) to refuse the entire access request merely because one disclosure was made to law enforcement.

82.4 A response may therefore need to separate:

1. ordinary personal-data processing;

2. ordinary recipient disclosures;

3. recipient information excluded by Section 11(2).

83. Internal investigations versus Section 11(2)

83.1 An employer investigates suspected theft by an employee and uses an external investigator acting on the employer’s instructions.

84. Section 11(2) does not automatically apply because:

• the investigator may be a Data Processor rather than another Data Fiduciary;

• there may be no written request from a legally authorised recipient;

• the investigation may be internal rather than an investigation under legal authority.

Key point

If police later issue a written request under lawful authority for investigation of an offence, that specific disclosure may satisfy Section 11(2).

84.1 The original internal investigation and the later police disclosure must be analysed separately.

85. Cybersecurity providers

85.1 A Data Fiduciary may share logs with a cybersecurity vendor for detection or investigation of a security incident.

If the vendor acts on behalf of the Data Fiduciary under a processor contract, Section 11(2) does not automatically exclude the vendor’s identity.

85.2 The subsection is directed to another Data Fiduciary authorised by law to obtain the information through a written request.

85.3 A processor hired to provide security monitoring is not necessarily such an authorised recipient.

This distinction prevents the phrase “cyber incident” from becoming a general basis to conceal every cybersecurity service provider.

86. Rule 14(3): Grievance timeline

87. Rule 14 requires every Data Fiduciary and Consent Manager to publish the period within which grievances will be answered.

Key point

That period must be reasonable and cannot exceed ninety days. Appropriate technical and organisational measures must be implemented to ensure the effectiveness of the grievance system within that period.

87.1 This provision concerns grievances.

87.2 It does not expressly prescribe a separate response deadline for the initial Section 11 access request.

Key point

Accordingly, it would be inaccurate to state that every Section 11 response must be provided within ninety days merely because Rule 14(3) establishes a maximum grievance-response period.

87.3 If the Data Principal raises a grievance concerning:

• failure to respond;

• incomplete response;

• excessive identification requirements;

• refusal to identify recipients;

87.4 the published grievance period, capped at ninety days, applies to the handling of that grievance.

Key point

The Data Fiduciary should still process rights requests within a reasonable operational period. The Act and Rule, as reproduced, do not specify an exact access-response deadline.

88. Rule 14(4): Nomination

89. Rule 14 also permits a Data Principal to nominate one or more individuals to exercise rights in accordance with:

• the Data Fiduciary’s terms of service;

• applicable law;

• the published means and particulars.

89.1 Nomination is principally governed by Section 14, but it may have practical consequences for Section 11.

89.2 Where the statutory conditions for nomination are met, a nominee may exercise the relevant rights on behalf of the Data Principal.

89.3 The Data Fiduciary should verify:

• the nomination;

• the nominee’s identity;

• the triggering circumstances under Section 14;

• any applicable legal requirements.

90. Rule 14 does not permit any family member to obtain access merely by asserting a relationship.

91. Security of the access response

91.1 A Section 11 response itself contains personal data.

91.2 The Data Fiduciary must therefore apply Section 8(5) and Rule 6 to the response process.

91.3 Relevant safeguards may include:

• identity verification;

• secure account delivery;

• encrypted transmission;

• time-limited download;

• access logging;

• prevention of misdirected email;

• restricted staff access;

• verification of guardians or nominees.

91.4 An access response sent to the wrong person may constitute a personal data breach.

Key point

The Data Fiduciary should balance security with accessibility. A process should not be so weak that information is disclosed to an impersonator, nor so burdensome that legitimate requests become practically impossible.

92. Third-party personal data in the response

92.1 A record relating to the Data Principal may also contain information about another person.

92.2 Examples include:

• email correspondence;

• complaint records;

• witness statements;

• family information;

• employee investigation reports;

• joint financial accounts.

93. Section 11 does not expressly prescribe how mixed personal data should be handled.

Key point

The Data Fiduciary should avoid unnecessary disclosure of another person’s personal data while still providing the requesting Data Principal with the summary required by the section.

93.1 Possible measures may include:

• summarising the relevant information;

• redacting unrelated third-party identifiers;

• separating the requester’s information;

• describing the processing without disclosing another person’s confidential details.

93.2 The section grants a right to a summary, which may permit an intelligible response without reproducing the complete mixed record.

94. Trade secrets, privilege and confidential information

95. Section 11 does not contain an express general exemption for:

• trade secrets;

• legal privilege;

• confidential business information;

• security architecture.

Key point

At the same time, the right is to a summary of personal data and processing activities, recipient identities and descriptions of data shared. It is not a right to every internal document containing the personal data.

95.1 A Data Fiduciary should not invoke trade secrecy to conceal:

• the existence of a personal-data category;

• the fact that a score is processed;

• the identity of a recipient;

• the description of data shared.

95.2 It may provide the statutorily required summary without disclosing:

• source code;

• privileged legal advice;

• complete security configurations;

• unrelated trade secrets.

95.3 Any refusal should be tied to the actual statutory scope or another applicable law, not a broad assertion of confidentiality.

96. AI and algorithmic processing under Section 11

97. Section 11 applies to personal data processed by AI systems in the same manner as other personal data.

97.1 The response may need to identify:

• inputs relating to the Data Principal;

• generated or inferred personal data;

• the processing activity performed;

• Data Processors or other Data Fiduciaries receiving the information.

98. AI inputs

98.1 Examples include:

• application data;

• transaction history;

• attendance;

• customer-support messages;

• photographs;

• location;

• behaviour.

99. AI-generated personal data

99.1 Examples include:

• fraud score;

• customer segment;

• predicted interest;

• applicant ranking;

• performance classification;

• risk category.

99.2 Where the output relates to an identifiable person and is being processed, it may form part of the personal-data summary.

100. No general model-explanation right

101. Section 11 does not expressly require disclosure of:

• model architecture;

• source code;

• training methodology;

• model weights;

• detailed decision logic.

101.1 The processing-activity summary should nevertheless identify the substantive operation accurately.

101.2 For example:

101.3 “Your transaction information is analysed using an automated fraud-detection system to assign a transaction-risk category.”

101.4 A response stating only “we use technology to improve services” would not meaningfully describe the activity.

102. Marketing and advertising

102.1 A Data Principal may use Section 11 to understand:

• marketing data being processed;

• behavioural or interest profiles;

• advertising identifiers;

• marketing processing activities;

• advertising processors;

• other Data Fiduciaries receiving the data;

• the information shared with each.

Key point

The section does not itself create an objection right against marketing. Consent may be withdrawn under Section 6 where marketing depends on consent, and correction or erasure may be requested under Section 12 where the statutory conditions apply.

102.2 The access response should distinguish between:

• contact information;

• consent records;

• customer segments;

• inferred interests;

• campaign history;

• audience disclosures.

Key point

A generic statement that “marketing partners may receive data” does not satisfy the requirement to identify all recipients where paragraph (b) applies.

103. Employees and Section 11

103.1 Employment processing demonstrates the importance of the prior-consent limitation.

103.2 An employer may process:

• payroll;

• attendance;

• performance;

• access logs;

• health-benefit information;

• disciplinary information;

• system monitoring.

103.3 Much of this processing may rest on Section 7(i), not consent.

103.4 The employee’s Section 11 entitlement therefore requires careful analysis of:

• whether consent was previously given to the employer;

• what processing that consent concerned;

• whether the broader or narrower interpretation of the opening words is adopted;

• whether another applicable law provides access to particular employment records.

Key point

An employer should not state without analysis that all workforce information is automatically excluded from Section 11 merely because Section 7(i) applies. Equally, the statute should not be misrepresented as creating an unrestricted employee-file access right.

Key point

Where the employer does provide a response, third-party information and confidential investigation material may need to be summarised rather than copied.

104. CCTV

104.1 CCTV footage is personal data where an individual is identifiable by or in relation to the footage.

105. Section 11 may require a summary explaining:

• that identifiable CCTV footage is processed;

• locations or contexts in which it is collected;

• security monitoring or incident-review activities;

• CCTV processors;

• other Data Fiduciaries receiving footage;

• description of footage or associated data shared.

106. Section 11 does not expressly require the Data Fiduciary to provide a video copy.

106.1 The right is to a summary of personal data and processing activities.

Key point

Where another person appears in the footage, providing a complete copy may expose third-party personal data. A summary may satisfy Section 11 without reproducing the full recording.

Key point

Where footage was shared with police through a written request satisfying Section 11(2), the identity of that recipient and description of the data shared may be excluded under paragraphs (b) and (c). The Data Fiduciary cannot rely on that fact to refuse the entire paragraph (a) summary.

107. Scraped and indirectly obtained information

Key point

If a Data Fiduciary processes information obtained through scraping or another indirect source, the Section 11 analysis first depends on the opening requirement of prior consent or Section 7(a).

107.1 If the Data Principal never gave consent to that Data Fiduciary, Section 11 may not be available on the literal statutory terms.

Key point

Where the right does apply, the personal-data summary should not be limited to information directly supplied by the Data Principal. It may include:

• scraped fields;

• linked records;

• inferred characteristics;

• generated scores;

• recipient disclosures.

Key point

Section 11(1)(c) could theoretically support future prescription of source information, but the current Rule 14 text does not prescribe a general right to know the source of indirectly obtained personal data.

107.2 A commentary should therefore not import the GDPR’s source-disclosure requirement into Section 11.

108. Children’s access rights

108.1 For a child, the definition of Data Principal includes the parent or lawful guardian.

108.2 The parent or guardian may therefore exercise the relevant Section 11 right, subject to:

• the opening consent condition;

• Rule 14 identification;

• applicable child-data arrangements.

108.3 The response may include:

• account data;

• educational data;

• location information;

• behavioural information;

• processing activities;

• processor identities;

• recipient disclosures.

Key point

The Data Fiduciary should consider the child’s own capacity and provide age-appropriate information where appropriate, but Section 11 does not prescribe a separate child-facing response format.

Key point

When the child turns eighteen, the organisation should ensure that the now-adult Data Principal can exercise the right directly and that the former parental-access arrangement does not continue automatically without legal basis.

109. Persons with disabilities and lawful guardians

Key point

Where the Data Principal is a person with disability whose lawful guardian acts on her behalf, the Data Fiduciary should verify guardianship in accordance with the applicable legal framework.

109.1 Disability alone does not authorise another person to receive the Data Principal’s personal-data summary.

109.2 The requesting person must possess lawful authority to act on behalf of the Data Principal.

109.3 The response mechanism should also be accessible. Depending on the Data Principal’s needs, this may require:

• readable formats;

• accessible website controls;

• assisted communication;

• clear language;

• compatible electronic formats.

Key point

The Act does not prescribe a universal accessibility format in Section 11, but a request mechanism that cannot be used by the relevant Data Principal may fail to enable effective exercise of the right.

110. Recordkeeping by the Data Fiduciary

111. Section 11 does not prescribe a specific access-request register.

111.1 The Data Fiduciary should nevertheless retain sufficient records to demonstrate:

• date of request;

• identity verification;

• scope;

• systems searched;

• response;

• recipients identified;

• application of Section 11(2);

• date of completion;

• grievance or escalation.

111.2 Recordkeeping supports:

• Section 8(4) effective observance;

• grievance handling;

• audit;

• regulatory inquiry;

• consistent responses.

111.3 The records should not be retained indefinitely without a purpose.

112. Refusal, partial response and grievance

113. Section 11 does not contain a detailed refusal procedure.

113.1 A Data Fiduciary may face situations where:

• the requester cannot be identified;

• the request concerns another person;

• the Data Fiduciary does not fall within the opening consent condition;

• information is outside the statutory summary;

• Section 11(2) applies;

• another law restricts disclosure.

Key point

Where a request is refused or partially answered, the Data Fiduciary should provide an intelligible reason sufficient to enable grievance redressal, unless another law prevents disclosure of that reason.

113.2 The Data Principal may use the grievance mechanism under Section 13.

Key point

Rule 14 requires publication of a grievance-response period not exceeding ninety days and implementation of measures to respond within that period.

114. What Section 11 does not provide

115. Section 11 should not be expanded beyond its words.

115.1 It does not expressly create:

• a right to a complete copy of all personal data;

• data portability;

• a right to know the source of every item;

• a right to source code;

• a general right to algorithmic explanation;

• a right to human review;

• a right to internal legal advice;

• a right to audit reports;

• a right to security architecture;

• a universal access right against every Data Fiduciary;

• a fixed access-response deadline;

• a right to know every law-enforcement disclosure.

115.2 Some of those matters may be governed by:

• another provision of the DPDPA;

• another law;

• contractual rights;

• sectoral regulation;

• future prescribed information under Section 11(1)(c).

115.3 They should not be attributed to Section 11 unless a legal basis exists.

116. Consolidated response structure

116.1 A response designed around the express words of Section 11 may contain:

116.2 A. Personal data summary

116.3 A clear description of personal-data categories currently being processed.

116.4 B. Processing-activity summary

116.5 A clear description of the principal operations undertaken on each category.

116.6 C. Other Data Fiduciaries

The identity of each other Data Fiduciary with which the relevant personal data was shared and a description of the information shared.

116.7 D. Data Processors

116.8 The identity of each relevant processor with which the personal data was shared and a description of the information shared.

116.9 E. Additional prescribed information

116.10 Any information prescribed under Section 11(1)(c), if and when applicable.

116.11 F. Law-enforcement limitation

116.12 Exclusion of recipient and prescribed information only where all Section 11(2) conditions are satisfied.

116.13 This structure is not a legally prescribed form. It directly follows the statutory heads and can help ensure that none is omitted.

117. Final interpretation

118. Section 11 is a carefully limited access right.

Key point

It does not grant a universal right to obtain every document, every historical record or every technical detail connected with personal data. It gives the Data Principal a right to obtain an intelligible summary of personal data currently being processed, a summary of the processing activities, the identities of other Data Fiduciaries and Data Processors with whom the information was shared, and a description of the information shared with them.

Key point

The right is expressly tied to the Data Fiduciary to whom the Data Principal previously gave consent, including the relationship contemplated by Section 7(a). The Act does not expressly extend Section 11 to every legitimate use in Section 7. It also leaves ambiguity where a Data Principal has consented to one activity but the same Data Fiduciary processes other information under another Section 7 ground.

Key point

Rule 14 provides the procedural mechanism. The Data Fiduciary must prominently publish the request means and the identification particulars required under its terms of service. Identification protects against unauthorised disclosure, but it should not become a device for discouraging requests or collecting unnecessary identity information.

Key point

The statutory word “summary” limits the right. The Data Fiduciary need not ordinarily disclose every database row, internal document, model weight, source code or complete record. The summary must nevertheless be meaningful. Broad labels such as “account data,” “analytics” or “partners” may not adequately explain the information and processing.

Key point

The disclosure right under Section 11(1)(b) requires actual recipient identities, not merely classes. It covers both processors operating on behalf of the Data Fiduciary and other Data Fiduciaries processing for independently determined purposes. Each recipient should be connected with a meaningful description of the personal data shared.

Key point

Section 11(2) creates a precise limitation, not a blanket government or law-enforcement exemption. It applies only where another Data Fiduciary is authorised by law to obtain the personal data, makes a written request, and seeks the data for the specified offence or cyber-incident purposes. Even then, it removes only the paragraph (b) and paragraph (c) disclosures. It does not, by its terms, eliminate the paragraph (a) right to a summary of the original Data Fiduciary’s processing.

The controlling proposition is

Section 11 requires a qualifying Data Fiduciary to make its processing intelligible to the Data Principal by summarising the personal data and processing activities and identifying the processors and other Data Fiduciaries that received the data, while preserving the narrow statutory confidentiality protecting legally authorised written requests concerning offences and cyber incidents.