Naavi.org

In Continuation of the earlier article on the emerging AI Guidelines 

Out of the nine AI-related guidelines identified in our earlier discussion, seven have already been examined on Naavi.org. We may revisit these documents at a later stage. For now, let us focus on the two new guidelines that deserve particular attention.

Let us examine the DSCI document and compare its approach with the philosophy adopted by DGPSI-AI.

1. Understanding the DSCI Discussion Paper on AI Liability

The DSCI document is titled “Discussion Paper on AI Liability: Industry Guidance for Agentic AI.” Its declared objective is to examine how existing legal principles and doctrines can be applied to emerging Agentic AI systems.

The document explains its purpose in the following words:

“This guidance is an attempt of providing an actionable framework to map established legal doctrines. It tries to bring together the realities of agentic systems, identifying where responsibility could shift and diffuse.”

The guidance identifies five groups of stakeholders whose involvement may contribute to an AI-related outcome resulting in liability:

1. 1. User organisations operating AI agents.
   2. Service providers and integrators operating AI-enabled workflows.
   3. Product companies and start-ups incorporating Agentic AI capabilities.
   4. Tool and framework providers whose resources are harnessed by AI agents.
   5. Cloud and infrastructure providers supporting AI agentic systems.

The Model Provider may also be considered a sixth element in the value chain.

The underlying philosophy of the guidance is that “framing AI liability as a choice between the end-user organisation and an upstream technology provider would be legally flawed, technically inaccurate, commercially paralysing and detrimental to maintaining a level playing field”.

Instead, the guidance advocates mapping responsibilities across the entire AI value chain.

It also argues:

“The AI models neither have operational context nor capacity to act, unless someone brings them to the enterprise environment. They provide the probabilistic intelligence. Primary focus of this guidance is therefore dedicated to the five groups.”

This is an important observation. An AI model, by itself, does not operate in an organisational environment. Its capabilities are brought into an operational context by other participants in the value chain.

However, an important question arises:

Does mapping responsibility across the AI value chain necessarily mean that the legal accountability of the AI deployer should be diluted?

We believe this is where the DSCI approach requires closer examination.

2. DGPSI-AI: Liability Must Begin with the AI Deployer

DGPSI-AI starts with a fundamental proposition: an organisation deploying an AI system must remain accountable for the consequences of its deployment, particularly when it is a Data Fiduciary under the Digital Personal Data Protection Act, 2023.

The DPDPA places statutory obligations on the Data Fiduciary even when personal data processing is undertaken through a Data Processor.

The Data Fiduciary cannot transfer its statutory obligations to a technology provider merely through a contractual arrangement.

The accountability of the Data Fiduciary towards the Data Principal is a statutory obligation and cannot be diluted by the complexity of the AI value chain.

There is, however, an important distinction between the regulatory accountability of the Data Fiduciary under the DPDPA and the personal remedies available to an affected individual.

The DPDPA establishes a regulatory enforcement framework, including adjudication of contraventions and imposition of penalties. It does not provide a general individual compensation mechanism for every loss suffered by a Data Principal.

For personal remedies, other applicable laws, including the Information Technology Act, 2000, may become relevant.

This distinction is fundamental to understanding the DGPSI-AI approach.

3. Section 11 of ITA 2000: Attribution of AI-Generated Electronic Records

Section 11 of the Information Technology Act, 2000 deals with the attribution of electronic records.

It recognises that an electronic record may be attributed to its originator when it is sent by an information system programmed by or on behalf of that originator to operate automatically.

This provision assumes considerable significance in the context of Agentic AI.

An AI agent may independently generate a recommendation, approval, rejection, instruction, communication or other decision output without direct human intervention at the time of generation.

Where such output constitutes an electronic record, the principles of attribution under Section 11 become relevant.

The fact that an output is generated autonomously by an algorithm should not, by itself, make the electronic record legally unattributable.

If an organisation deploys an AI agent, authorises its functions and permits it to generate electronic communications or instructions on its behalf, there is a strong basis for examining the attribution of those records to the organisation.

There is a distinction between attribution and liability. Section 11 identifies the legally relevant originator in the circumstances covered by the provision. The substantive liability arising from the electronic record or its consequences must still be established under the applicable law.

Nevertheless, the principle is important.

An AI agent cannot become a legal shield behind which the deployer avoids responsibility merely because the output was generated autonomously.

Section 11 provides an important statutory foundation for this interpretation, although its precise application to different types of AI-generated decisions may require judicial clarification.

4. Section 43 and Section 46: Personal Remedies for AI-Related Data Breaches

The relationship between Sections 43 and 46 of the ITA 2000 is particularly important in the context of AI-related data breaches.

Section 43 identifies specified unauthorised acts involving computer resources and provides for compensation to persons affected by such acts.

Section 46 provides the adjudication mechanism for determining contraventions and compensation claims falling within its jurisdiction.

Thus, Section 43 identifies the actionable conduct and Section 46 provides the mechanism through which the claim can be adjudicated.

A data breach that also results in regulatory consequences under the DPDPA may independently attract examination under Section 43 of the ITA 2000.

However, every DPDPA violation does not automatically constitute a Section 43 violation. The ingredients of the relevant clause of Section 43 must independently be satisfied.

This distinction is important.

The DPDPA determines the statutory accountability of the Data Fiduciary for personal data processing. The ITA 2000 may provide a separate route for personal compensation where the facts satisfy its requirements.

The significance of Section 43(g)

Section 43(g) deals with providing assistance to facilitate unauthorised access to a computer resource.

An important judicial interpretation of this provision is found in S. Umashankar v. ICICI Bank, decided by the Telecom Disputes Settlement and Appellate Tribunal (TDSAT).

In this case, the question arose whether negligence in maintaining security arrangements could amount to assistance in facilitating unauthorised access.

The Tribunal adopted an interpretation that recognised that assistance need not necessarily involve an affirmative act. An omission arising from negligence could also amount to assistance in appropriate circumstances.

The Tribunal illustrated this through the example of a watchman who facilitates theft by negligently remaining absent from duty or switching off the security light.

This interpretation is significant for AI governance.

Consider an organisation that deploys an AI system with access to personal data and other computer resources.

If the organisation fails to implement appropriate access controls, grants excessive privileges to an AI agent, neglects known vulnerabilities or fails to monitor the agent’s activities, and such failures facilitate unauthorised access, Section 43(g) may become relevant.

The question would not merely be whether the AI algorithm was defective.

It would also be whether the deployer, through its own acts or omissions, facilitated unauthorised access.

The Umashankar judgment therefore provides an important legal basis for examining negligence in the context of Section 43(g).

The significance of Section 43(i)

Section 43(i) addresses destroying, deleting or altering information residing in a computer resource, or diminishing its value or utility or affecting it injuriously by any means.

This provision is also relevant to Agentic AI.

An autonomous AI agent may be authorised to modify, delete, reorganise or process information.

If it undertakes an unauthorised alteration or deletion of information, the consequences may need to be examined under Section 43(i).

For example, an AI agent operating in a banking environment may delete transaction records, alter customer information or modify information residing in a computer resource beyond its authorised scope.

If the statutory ingredients are satisfied, the fact that the action was performed autonomously by an AI algorithm does not necessarily remove the possibility of liability.

The attribution of the action, the authority under which the system operated and the conduct of the deployer would all become relevant.

Thus, Sections 43(g) and 43(i) offer two different but potentially important routes for examining AI-related security failures and unauthorised data operations.

Negligence and reasonable security practices after the repeal of Section 43A

Section 43A of the ITA 2000 specifically addressed compensation arising from negligence in implementing and maintaining reasonable security practices and procedures while handling sensitive personal data or information.

However, Section 44(2) of the DPDPA provides for the omission of Section 43A, which becomes effective on 13 May 2027 under the notified commencement schedule.

Does this mean that negligence and reasonable security practices will cease to have relevance under the ITA 2000 after that date?

We believe that such a conclusion would be incorrect.

Section 43A is a specific provision dealing with negligence in the context of sensitive personal data and information. Section 43 contains separate provisions addressing unauthorised acts involving computer resources.

The interpretation adopted by TDSAT in the Umashankar case demonstrates that negligence may be relevant to establishing assistance under Section 43(g), where the necessary connection with unauthorised access is established.

Therefore, the repeal of Section 43A does not automatically eliminate the relevance of negligence, due diligence and reasonable security practices when examining conduct independently falling within Section 43.

It is important, however, not to equate every failure to maintain reasonable security practices with a violation of Section 43. The specific ingredients of the relevant clause must still be established.

The important point is that the legal relevance of due diligence and reasonable security practices is not confined exclusively to Section 43A.

This has significant implications for DGPSI-AI.

The deployer’s due diligence in selecting, authorising, supervising and monitoring AI service providers and Data Processors is not merely a contractual governance requirement.

Depending on the facts, failures in these areas may also become relevant in determining whether the deployer has facilitated an unauthorised act under Section 43(g), or whether an unauthorised alteration or deletion has occurred under Section 43(i).

5. Section 72A: Contractual Accountability Between the Data Fiduciary and Data Processor

Section 72A of the ITA 2000 introduces another important legal dimension.

It addresses the disclosure of personal information in breach of a lawful contract, subject to the conditions specified in the provision.

In an AI value chain, the relationship between a Data Fiduciary and a Data Processor is ordinarily governed by a contract.

If a Data Processor obtains personal information while providing services under such a contract and subsequently discloses it in circumstances satisfying Section 72A, the provision may become relevant.

This creates an additional statutory consequence associated with contractual confidentiality obligations.

Section 72A does not create general liability for every contractual breach or defective AI output. Its application is confined to the conduct specified in the provision.

Nevertheless, it reinforces the importance of contractual accountability.

DGPSI-AI recognises that the relationship between successive participants in the AI value chain must be supported by appropriate contractual arrangements.

The AI deployer may have a contract with a system integrator. The integrator may have a separate contract with a product developer. The developer may have contractual relationships with model providers, tool providers and infrastructure providers.

Each relationship should establish appropriate responsibilities, warranties, indemnities, audit obligations, security requirements and remedies.

This creates a chain of enforceable obligations without requiring the affected Data Principal to investigate and pursue every upstream participant.

The affected person can seek remedies against the entity legally accountable to them, while that entity may pursue appropriate remedies against its immediate contracting party.

This is the contractual architecture advocated by DGPSI-AI.

6. The DSCI Approach versus the DGPSI-AI Approach

The DSCI guidance appears to distribute responsibility for Agentic AI outcomes across multiple participants in the value chain.

While this may be useful for identifying where a technical failure originated, it raises a fundamental question concerning the rights of the end user.

Consider a bank that deploys an Agentic AI system for processing customer transactions.

The bank may have obtained the AI solution through an integrator, who relies on a product developer, a model provider, a tool provider and a cloud infrastructure provider.

If an adverse outcome occurs, should the affected customer be required to identify the precise technical failure and pursue the entity responsible for it, even if that entity is four or five contractual layers removed from the customer?

In our view, this is impractical.

The customer has a direct relationship with the bank. The bank has chosen to deploy the AI system and has authorised the scope of its autonomous operations.

The bank’s applicable legal obligations towards the customer cannot be avoided merely because the error originated in an upstream technology component.

The bank may subsequently seek indemnification or other remedies from the relevant technology provider.

This distinction is essential.

There are three different questions:

1. 1. Who is legally accountable to the affected person?
   2. Which participant contributed to the technical or operational failure?
   3. Who should ultimately bear the financial consequences?

These questions need not have the same answer.

The DSCI guidance may be useful in addressing the second and third questions. However, it should not become a basis for diluting the deployer’s accountability towards the affected person.

7. The DGPSI-AI Human Handler: More Than a Human-in-the-Loop

Another important contribution of DGPSI-AI is its concept of the Human Handler.

Many AI governance frameworks emphasise Human-in-the-Loop arrangements. These arrangements are intended to ensure that human beings can review, approve, reject or intervene in AI-generated decisions.

Such mechanisms are important safeguards, but they do not necessarily resolve the question of legal accountability.

DGPSI-AI introduces the Human Handler as a distinct concept.

The Human Handler is not merely a person who monitors the algorithm or intervenes when something goes wrong. The Human Handler is the designated human authority who bears legal responsibility for the algorithm within the defined scope of its authorised operation.

The distinction can be summarised as follows:

Human-in-the-Loop	Human Handler
Primarily an operational safeguard	Primarily a legal accountability mechanism
Reviews or intervenes in AI decisions	Bears defined responsibility for the AI algorithm
May be involved only at selected decision points	Has continuing responsibility for the authorised deployment
Intended to reduce errors and risks	Intended to prevent an accountability vacuum
Does not automatically establish legal liability	Is designated as the person bearing legal responsibility under the DGPSI-AI governance model

The distinction is fundamental.

The Human-in-the-Loop is a guardrail. The Human Handler is the designated bearer of accountability.

DGPSI-AI therefore advocates a stronger accountability model than merely requiring a human being to participate in selected AI decisions.

The Human Handler concept must, of course, operate consistently with the statutory responsibilities of the organisation. An internal designation cannot automatically transfer the Data Fiduciary’s statutory liability to an employee.

However, it ensures that an organisation cannot treat an AI algorithm as an independent decision-making authority without an identifiable human accountability structure.

The Human Handler is not merely expected to watch the algorithm. The Human Handler is expected to take responsibility for the algorithm.

8. Agentic AI: Autonomy Cannot Become an Excuse for Avoiding Liability

Agentic AI introduces a new dimension to accountability.

Unlike conventional AI applications, an Agentic AI system may independently select tools, plan actions, interact with other systems and execute decisions within an authorised operational environment.

However, this autonomy is not self-created. It is granted by the deployer.

The organisation decides whether to use Agentic AI, what functions to delegate, what operational boundaries to establish and what safeguards to implement. Consequently, the responsibility for granting autonomy must remain with the deployer. The organisation cannot reasonably argue that the AI agent acted independently and therefore the organisation should be relieved of its legal obligations.

The doctrine of caveat emptor, or Buyer Beware, should not be used to transfer the consequences of an AI deployment to an affected person who had no role in selecting or configuring the system.

The principle advocated by DGPSI-AI is straightforward:

The entity that authorises an AI agent to act must remain accountable for that authorisation and its legally attributable consequences.

This does not prevent the deployer from establishing the responsibility of upstream technology providers or pursuing contractual remedies against them. It merely ensures that autonomy does not become a convenient means of escaping accountability.

9. The Kill Switch: DGPSI-AI Advocates an Independent Emergency Stop

The DSCI guidance also appears to adopt a different approach to intervention mechanisms.

It recommends that intervention should not be limited to a single blanket action but should operate through a hierarchy of controls.

There is merit in this proposition. Depending on the nature of the risk, an organisation may wish to restrict a particular tool, suspend a transaction, disable a workflow or stop an entire AI system. Such graduated interventions can be useful in managing complex AI deployments.

However, DGPSI-AI goes one step further.

It recommends that an AI system should have an independent Kill Switch capable of immediately halting the relevant autonomous operation when necessary.

The independence of the Kill Switch is crucial.

If the mechanism for stopping the AI system depends entirely on the same algorithm whose operation has become unsafe, the effectiveness of the safeguard may be compromised.

The emergency stop mechanism should therefore be designed to operate independently of the main AI decision-making algorithm.

A hierarchy of interventions may be useful for normal risk management, but it should not replace the availability of an independent emergency stop.

Both mechanisms can coexist.

The DSCI approach can provide graduated operational controls, while DGPSI-AI ensures the availability of a final independent intervention mechanism.

10. A Three-Layer Approach to AI Liability

The discussion brings us to a fundamental distinction that should guide the development of AI liability principles in India.

There are three separate dimensions of liability.

First: Accountability towards the affected person

This is determined by applicable statutory and other legal obligations.

Where the AI deployer is a Data Fiduciary, its obligations under the DPDPA remain with it, even when processing is undertaken by a Data Processor.

Where a compensable wrong has occurred under another applicable law, the affected person should have access to the corresponding legal remedy.

Second: Attribution and responsibility for the AI action

This involves identifying the person or organisation to whom the AI-generated action or electronic record can legally be attributed.

Section 11 of the ITA 2000 provides an important basis for examining the attribution of electronic records generated by automated information systems.

Sections 43(g) and 43(i) provide additional legal provisions for examining qualifying unauthorised access, assistance and unauthorised alteration or deletion of information.

The DGPSI-AI Human Handler concept adds a proposed layer of identifiable human accountability.

Third: Allocation of liability across the AI value chain

This concerns the respective responsibilities of the deployer, integrator, developer, model provider, tool provider and infrastructure provider.

These responsibilities may be determined through contractual obligations, indemnities, statutory duties and other applicable legal principles.

The DSCI guidance may be particularly useful in addressing this third dimension. However, the third dimension should not be permitted to undermine the first two.

11. Conclusion: AI Liability Must Not Become a Game of Passing the Buck

The DSCI Discussion Paper is a welcome contribution to the emerging debate on Agentic AI liability. Its attempt to map responsibilities across the AI value chain can assist organisations in identifying sources of risk and designing appropriate contractual and operational safeguards.

However, the legal framework must not become so complicated that the affected person is left searching for an accountable entity somewhere within a multilayered technology ecosystem. India already has important legal provisions relevant to this discussion.

Section 11 of the ITA 2000 provides a foundation for attribution of electronic records generated through automated information systems.

Sections 43(g) and 43(i) provide legal grounds for examining specified unauthorised access-related assistance and unauthorised alteration or deletion of information.

Section 46 provides the adjudication mechanism for compensation claims falling within its jurisdiction.

The Umashankar judgment demonstrates that negligence may be relevant to determining assistance under Section 43(g), where the statutory requirements are satisfied.

The repeal of Section 43A on 13 May 2027 does not automatically eliminate the relevance of due diligence and reasonable security practices under other applicable provisions of the ITA 2000.

Section 72A provides an additional statutory dimension for specified contractual disclosures of personal information.

The DPDPA establishes the statutory accountability of the Data Fiduciary for personal data processing undertaken on its behalf.

DGPSI-AI builds upon these legal foundations and proposes an accountability architecture based on:

• • The deployer’s continuing statutory accountability.
  • Attribution of AI-generated electronic records.
  • Due diligence and reasonable security practices.
  • Contractual allocation of upstream responsibilities.
  • A designated Human Handler.
  • An independent Kill Switch.

The objective is not to exempt developers, model providers or infrastructure providers from liability. Nor is it to impose every conceivable liability on the deployer irrespective of the applicable law.

The objective is to ensure that the affected person is not denied an effective remedy merely because the AI system operates through a complex value chain.

The principle that should guide Indian AI governance is therefore:

“AI autonomy cannot dilute human accountability, and the complexity of the AI value chain cannot become an excuse for denying legal remedies to the affected person.”

The DSCI guidance would become more useful if its mapping of value-chain responsibilities were explicitly aligned with this principle.

DGPSI-AI offers a possible foundation for such an approach.

We welcome alternate views and invite legal professionals, AI developers, Data Protection Professionals and Independent Data Auditors to contribute to this important discussion.

Naavi

In yesterday’s post, we listed the following eight AI guidlines that have been released by different organizations in India.

1. DGPSI-AI  (Naavi/FDPPI): A DPDPA framework for Data Fiduciaries who carry AI risk either directly or through the processors. It mainly addressed the implementation specifications for the deployer and added the obligations of  adevloper or licensor to be enforced contractually by the Data Fiduciary.
2. AIGSI or Artificial Intelligence Governance Standard of India.   (Naavi/FDPPI) Released recently as a comprehensive Standard for AI developers and deployers. Current version is for discussion and would be updated with the other frameworks now available.

3.  AI Governance guideline . (Meity): A framework for AI Innovation released by the MeitY. Also discusses some aspects of accountability but placed “Innovation” over “Restraint” as the basic principle.

 4. AI usage in vulnerability analysis .  (CERT): This document highlights the need for use of AI for fighting AI vulnerabilities.

5. Model Risk Management Framework.  (RBI): This is a specific guideline issued by RBI as a regulator to its regulated entities. It contains several AI principles like human supervision and killer switch that were advocated in DGPSI-AI.

6. Guideline for AI usage in Judiciary (Supreme Court): Supreme Court issued a set of guidelines for use of AI in Judiciary which had its own organizational set up.

Naavi.org has already discussed these guidelines in detail in earlier posts.

In the last few days two more guidelines have appeared.

 7. security audit guideline on November 4, 2026 for AI. (CERT In). This is an “Audit framework” for AI security and is relevant for DGPSI AI also. We shall discuss this now separately

8. Discussion paper on AI Liability (DSCI): Released by DSCI for discussion on how accountability for AI need to be fixed across the value chain.

9. National Framework for AI  from NITI Ayog. This was released in 2018 and was added to the list of other 8 frameworks so that the unification of the framework will cover this framework also. This framework highlighted the key challenges and a way ahead for AI adoption in India from the NITI Ayog perspective.

FDPPI will now attempt an upgradation of AIGSI which we shall call for the present “Unified AIGSI” to recognize the contribution from multiple sources.

Watch out for the developments…

Naavi

Naavi and FDPPI pioneered the formal guidline for AI regulation with the release of DGPSI-AI in September 2025. We had also subsequently released a discussion version of AIGSI or Artificial Intelligence Governance Standard of India. 

In  November 2025, Government of India released an AI Governance guideline .

CERT In had released a guideline for AI usage in vulnerability analysis . Also RBI had issued its own Guideline in the form of Model Risk Management Framework. Supreme Court had also released a guideline for AI usage in Judiciary

In the last few days two more guidelines have appeared.

CERT In has issued another security audit guideline on November 4, 2026 for AI.

A few days back, DSCI also released a discussion paper on AI Liability

There are now eight different documents discussing different aspects of AI. As we move towards a AI regulation for India, it would be an interesting discussion to have on these 8 documents and how they address different aspects of AI regulation.

FDPPI would like to release a consolidated discussion paper on the above in the IDPS 2026 either at bangalore on November 21, 2026 or on November 28 2026 at Hyderabad.

Contribute your thoughts if any.

Naavi

P.S: We shall add Niti Ayog framework for AI.  This is a old document of 2018 but thought that it should be added to this list to make it comprehensive. This makes it the  ninth document to be referred to in this project for “Unified AIGSI”.

Continued

In discussing DPDPA today, we can recall certain aspects of Information Technology Act 2000 which are relevant.

The Information Technology Act 2000 (ITA 2000) was designed as a law for electronic documents, not for computers. It defined what an electronic record is, and it treated the devices that create and use such records as “computer” devices. This approach let the law keep pace as computers took new forms such as mobiles, kiosks and embedded systems.

The same design explains why Section 11 of ITA 2000 remains relevant today. It attributes an electronic record to its originator, including a record generated by an information system programmed to operate automatically on the originator’s behalf. By extension, Section 11 attributes the outputs of an automated system, including an AI, to the person who deployed it.

The DPDPA has a similar resilience when we read it as a law of personal data. Those who handle personal data in a particular way are defined as Data Fiduciaries, and obligations are cast on them. But it is clearer to see the Act as a law of digital personal data than as a law regulating Data Fiduciaries. Just as the Information Technology Act was a law for information, the DPDPA is the law for digital personal data.

Following the data in a bank

If the law follows the data, governance must follow the data too. A bank has numerous end points where personal data is collected, processed, disclosed and disposed of. The most visible of these are its branches.

Accountability stays with the Bank.

Currently, we consider that the Data Fiduciary is the Bank as a single legal entity, answerable through its Board. Branches are not separate fiduciaries. What is distributed across the organisation is implementation and evidence of compliance, not accountability. Given their scale and the sensitivity of the data they hold, banks can also be expected to be notified as Significant Data Fiduciaries. That brings in the obligations of a Data Protection Officer, independent data audit under Section 10, and periodic Data Protection Impact Assessments.

Whether this interpretation has to stay as it is or modified to consider each branch unit as a “Micro Data Fiduciary Element” and the Bank as an “Aggregation of such Units” is the jurisprudential thought that needs consideration.

Personal data enters through two kinds of channels:

• Physical entry points. Branches collect data from customers and from many non-customers. These include guarantors, nominees, joint holders, payees and beneficiaries, walk-in enquirers, visitors captured on CCTV and in visitor registers, and job applicants.
• Digital entry points. A growing share of data reaches the Bank without passing through a branch:
  • mobile and internet banking
  • Video-KYC onboarding
  • Account Aggregator and API flows
  • call centres
  • Central Processing Centres

Intermediaries add a further layer. Business Correspondents, Direct Selling Agents and collection agents also collect personal data on the Bank’s behalf. They may be  Data Processors or Joint Data Fiduciaries (Those who determine the means of processing in conjunction with the Bank)  and must be governed through contracts and oversight.

Branches also hold data in paper form, such as application forms, registers and documents awaiting scanning. The DPDPA applies to such data once it is digitised, so branch-level governance must clearly define how and when paper records enter the digital regime.

Who needs identified data?

The Head Office maintains the IT architecture, including the Core Banking System, and is guided by the RBI as the sectoral regulator. The CBS holds data originally collected by branches and other channels. Not every function at the HO, however, needs that data in identified form.

Some functions have a specific legal or security purpose for identifiable data:

• fraud management
• KYC/AML compliance and suspicious transaction reporting to FIU-IND
• CKYC uploads
• credit bureau and regulatory reporting
• grievance redressal
• recovery and legal

Other functions, such as marketing analytics, MIS and policy planning, can work on pseudonymised or anonymised data.

Pseudonymised is not anonymised.

Pseudonymised data remains personal data under the DPDPA; only properly anonymised data may fall outside it. So marketing may analyse pseudonymised data, but re-identifying a customer for outreach needs its own lawful basis, ordinarily consent.

If prospective marketing candidates are first identified on the basis of processing of pseudonymised data, the monetization of these contacts (eg:HNW prospects) can be for a far lesser number of customers and obtaining consents could be easier.

The Data Minimisation principle is therefore best implemented through purpose-based access. Identifiable data is made available only to functions that need it for a defined purpose, and in pseudonymised or anonymised form to everyone else.

The three-tier structure

DPDPA governance in a bank should therefore be designed differently for the Head Office, the Regional Office and the Branches. Employee data, handled across all tiers, is best treated as HR information under DGPSI-HR.

The HO follows the full DGPSI framework, with suitable accommodation for delegated implementation of its policies at the branches. The RO assures that this delegation actually works. The branches apply DGPSI-Lite to the customer and non-customer data that passes through their counters.

Aligning with the sectoral regulator

This structure is meant to complement the RBI’s regulatory framework, including its emerging guidance on data governance, not to run parallel to it. DGPSI-Bank maps the DPDPA’s obligations onto a bank’s existing hierarchy of HO, RO and branches. In this way, compliance follows the data along the same lines through which the bank already governs its business.

This is a basic structure that may be considered for implementing the DGPSI-Bank framework, and it can be refined further as RBI’s guidance is finalised.

Naavi

(This discussion continues and will be part of the DGPSI-Compliance Branch Manual being prepared by Naavi. Comments are welcome)

Audio Review: