Naavi.org

After DPDPA 2023 has become a reality, there is a scramble to find a framework of compliance which can assist organizations in implementing a Data Governance and Protection Management System (DGPMS) which can provide “Compliance by Default and Design”.

The key compliance requirement of the Act is contained in Section 4(1) of the Act which says

A person may process the personal data of a Data Principal only in accordance with the provisions of this Act (a) for which the Data Principal has given her consent; or (b) for certain legitimate uses.

Consent or legitimate use is a necessary aspect of the obligation but not “Sufficient”. The obligations cover all the other provisions of the Act which need to be taken into account.

An organization that needs to be compliant with DPDPA 2023 cannot rely on the existing frameworks such as ISO 27001 which addresses only one aspect of compliance namely how to preserve the confidentiality, integrity and availability of personal information to those who have a need to know or ISO 27701 which extends the ISO 27001 to legal basis of processing and rights of data principals under GDPR.

While there is always a possibility of adapting ISO 27001 or ISO 27701 to compliance of DPDPA 2023, if the implementer is innovative enough, the need for India to develop its own framework to directly address DPDPA Compliance has arisen with the passing of DPDPA which is not GDPR.

If DPDPA is not GDPR, it seems not logical that we should use ISO 27701 for DPDPA Compliance.

The TINA principle (There is no alternative) is unfortunately not applicable in favour of ISO 27701 since FDPPI has been working on the alternative in anticipation of the law being passed in India. Accordingly, PDPSI or Personal Data Protection Standard of India was introduced after PDPB 2018 was released and progressively upgraded to PDPB 2019, DPA 2021 and DPDPB 2022 is now available as DGPSI or Digital Governance and Protection Standard of India.

DGPSI recognizes that compliance of DPDPA 2023 requires also compliance of ITA 2000 since there are some sections of ITA 2000 which are relevant even after DPDPA 2023 comes into existence.

For example, we can recall Section 72A of ITA 2000 which states

(72A of ITA 2000) Penalty for Disclosure of information in breach of lawful contract

Save as otherwise provided in this Act or any other law for the time being in force, any person including an intermediary who, while providing services under the terms of lawful contract, has secured access to any material containing personal information about another person, with the intent to cause or knowing that he is likely to cause wrongful loss or wrongful gain discloses, without the consent of the person concerned, or in breach of a lawful contract, such material to any other person shall be liable to pay penalty which may extend to twenty-five lakh rupees

This section will continue to apply even after DPDPA 2023 comes into being.

Similarly there are several other sections of ITA 2000 applicable to Personal Data Breach that needs to be complied with by a Data Fiduciary as well as a Data Processor.

Hence DGPSI framework recognizes and incorporates ITA 2000 compliance requirements also to the implementation framework which ISO 27001/27701 may not consider.

As a bonus DGPSI also includes part of the Bureau of Indian Standard draft guidelines on “Adequacy of Data Governance and Data Management System” meant for data driven organization which recognizes Data as a valuable asset of a company which is recommended to be managed in a particular manner.

As a result, DGPSI has emerged as the Gold standard for a Compliance framework for DPDPA and perhaps the only standard for implementation.

The fact that it is also available for Certification makes it a TINA in the reverse. As of now there is no alternative to DGPSI as a framework for DPDPA 2023. The framework also accommodates Data Trust Score as a tool of assessment which can be expressed as a Score for good visibility to the management.

A Glimpse of what DGPSI represents can be captured in the 12 key principles that are the foundation of the framework depicted below.

At the end of this short discussion organizations need to only ask themselves ….

Why run around searching for compliance framework. Why Not DGPSI?

Naavi

(Continuation of the previous article)

One of the key aspects of DPDPA 2023 is the recognition of some Data Fiduciaries as “Significant Data Fiduciaries” (SDF). The SDF would have responsibilities to appoint a DPO, a Data Auditor and conduct DPIA periodically in addition to other obligations.

Since the Act has not defined “Sensitive Personal Information” but incorporated “Sensitivity” as a criteria for defining the SDF, it is expected that the Government is thinking of a combination of “Sensitivity” and “Volume” to define an SDF.

When we define the role of an organization as a “Data Fiduciary” or “Data Processor”, we take note that an organization is an aggregation of multiple processes involving personal data processing and in all those processes, they may be determining the purpose and means.

In most cases they may be using the services of data processors to process the data for the purpose for which it has been collected by the data fiduciary but in a manner which is at the discretion of the processor and protected by their Intellectual Property right. In other words, the “Means of Processing” will be under the control of the processor. In such cases the “Processor” is to be recognized as a “Joint Data Fiduciary”.

Similarly there are processes in which an organization may be a Data Processor of some other Data Fiduciary.

If we place the tag of “Data Fiduciary” and “Data Processor” on the entity as a whole, it will not reflect the role of the entity in the specific context.

This raises the question Why Not we recognize the role of an entity with reference to the specific process? so that the entity can be a data fiduciary in one process and a data processor in another?

This concept can be implemented by considering an organization as an aggregation of processes and the focus of compliance being placed on a process. Every process has an input of personal data, certain modifications that occur within the process and thereafter creation of an output which is stored or disclosed or fed into another process as an input. With this concept of a “Compliance Entity being an aggregation of processes”, we can make the role definition “Process Centric”. This requires an inventory of processes to be developed with identification of input, purpose of processing and output. If the role of the entity in that process is as a “Processor”, then the compliance requirement would be based on the processing contract issued by the data fiduciary who has entrusted the processing to the entity. If the role of the entity in the process is that of a Data Fiduciary, then the compliance framework has to be the DPDPA2023.

In this approach, the entity will be considered as a “Hybrid Entity” of process centric role as a data fiduciary or a data processor. Different compliance controls will be applicable to the different processes.

I hope the discussion upto this point is non controversial and implementable. People will recognize that even GDPR wants a creation of ROPA (Record of Processing Activities) and this suggestion adopts the ROPA principle. However, I am not sure if a thought has been given to the fact that an organization can be both a Data Fiduciary (or Data Controller) and a Data Processor at the same time.

This multiple identity recognition is essential since if we recognize the role of a Data Fiduciary and Data Processor at the entity level, then every organization would be a data fiduciary and here is no pure data processor. In such a case all entities under GDPR would be liable for obligations of a Controller and all entities under DPDPA 2023 would be liable as Data Fiduciaries since we can find at least one personal data processing in every organization where it would determine the purpose and means of processing by itself.

I hope we can now ask the question Why Not an entity can be a data fiduciary and a data processor at the same time for different processes and manage its compliance with reference to DPDPA 2023 in certain processes and with reference to the vendor contract in other processes?

Having crossed this stage of debate, we now come to the more difficult part of segregating processes themselves on the basis of “Sensitivity” and “Volume”. In other words, Can some processes be more sensitive than others? Obviously yes. If so, Why Not distinguish processes on the basis of “Significant” and “Not Significant”?.

If so, we can consider an entity as a SDF in one process, ordinary data fiduciary in another process and a data processor in yet another.

Some will say ..Oh! we are suggesting a system of Compliance with a concept which even the GDPR has not mandated.

But I would like to ask the question Why Not?

The solution that emerges is that the operations of an organization shall be considered as an aggregation of multiple processes and in each process, identify the purpose and its sensitivity and classify the “Process” as a “Significant Process”. The entity will be a “SDF” only in the context of this process and not otherwise.

This means that the DPO need to be a leader of all Significant Personal Data Processes and mandatory conduct of DPIAs applies only to that process.

Since the classification of processes into Significant or otherwise is part of the “Risk profiling” of the Company, the Data Auditor would audit the system of how some processes were classified as significant and others were not. But there after his focus also could be only on the Significant Data Processes.

This thought process of SDP (Significant Data Process) instead of SDF (Significant Data Fiduciary) will simplify the compliance and appears logical.

This suggestion takes a fresh view of the “Data Flow Diagram”. The Personal Data Flow diagram need to indicate the flow from process to process and hence instead of recording from which device data flows into which other device, it has to record from which process it moves to which other process. Each process however represents an application executed in some device and will have a Process owner (who may also be a device owner) and associated with the details of the process similar to what is indicated in the Article 30 of GDPR. The Controls need to be established in such a manner that they are associated with the relevant processes based on the Compliance requirements related to the process.

Comments are welcome.

Naavi

(Continued from Previous Article)

The MeitY is now trying to finalize the rules under DPDPA 2023. From the indications now available, the ministry is trying to release a complete set of 25/26 rules rolled into one notification.

In the last couple of days we have discussed Why Not the Consent Manager under DPDPA be different from Consent Manager under DEPA.

Similar Why Not? questions will be raised in this series of articles so that some thoughts can be implanted in the minds of the rule makers so that they may consider them in the draft rules to be released for public comments or enable a discussion on the same.

It is noted that the MeitY is under closed door discussion with industry so that there is a prior approval of the rules from them.

It is noted that the “Data Sovereignty” principle of Cross Border restriction on data transfer which was present in the earlier drafts has been diluted. Similarly Section 9(5) was perhaps introduced at the behest of FaceBook that the restrictions on parental consent should be relaxed for children below the age of 18 upto the age of 12/13.

Now the delay in the issue of rules is perhaps influeced by the fact that there is no consensus on some of the aspects of the rules..

Hence we are trying to put up some suggestions in the “Why Not Series” so that a record is created that these issues were raised whether they are accepted or not.

The discussion on “Why Not the Consent Manager under DPDPA be different from the Consent Manager under Account aggregator/DEPA scheme was also in this direction.

We shall raise more such “Why Not” questions in the next days till the rules are finally notified after public debate.

I invite professionals to actively participate in this debate. Some of the good practices that come forth here would be also incorporated in the DGPSI implementation recommendations so that the DGPSI framework becomes “A Voice of the Data Protection Professionals”.

Naavi

(Continued from previous article)

One of the major issues of AAs (Account Aggregators) is the need to ensure the strict following of the “Fit and Proper” criteria to ensure that the valuable personal data that may come into the hands of the AA from the Banks is not used in contravention of DPDPA.

While the RBI is responsible to check the “Fit and Proper” criteria at the time of providing provisional license, REBiT is responsible for ensuring that the technology platform is set up as per the RBI directives. In the coming days the system needs to be compliant also with DPDPA.

We are not aware that RBI and REBiT are taking adequate steps to ensure that personal data of the Indian public which may be accessed by AAs are adequately secured from the perspective of Data Privacy.

There is also a distinct possibility that the “Fit and Proper” adherence of an organisation may change after the licensing. Hence it has to be followed up at periodical intervals and monitored continuously.

We may recall the experience with CIBIL which started as a trusted organization of Indian Banks and once it accumulated nearly 500 million data sets of Indian Bank customers, quietly sold itself to a US private company. Who benefitted in this multi billion dollar deal remains a mystery which even the ED has ignored.

There is already an attempt by some US based tech companies to enter themselves into NPCI and it is not known how successful they have been at present. If they are accommodated like TransUnion was, in the original CIBIL capital structure, they will eventually take over NPCI control. We should remember the famous story of the Arabian Camel getting into the tent and guard against it.

Similar possibility exists in the AA system and the risk of inadequate fitness at the time of licensing and change in the “Fit and Proper” criteria after licensing as well as change in the “Security posture” after REBiT audit needs to be flagged and countered.

Presently there is no publicly accessible report about the licensed AAs and how RBI documented the “Fit and Proper” criteria or recorded the technology audit.

We donot see the AAs subjecting themselves to the “Right to Information Act” and provide for any information disclosure on their websites.

Some quick observations indicate:

Anumati ownership has already changed hands from Agya Technologies Pvt Ltd to Perfios AA pvt Ltd.

CAMS FinServ grievance redressal page does not seem to work.

Finvu has a Grievance redressal officer contact but no DPO at present. The escalation of the grievance is to RBI which needs to change if DPB becomes the authority under law.

CRIF CONNECT is a company with parentage in Italy and operates in data analytics indicating the potential conflict.

Privacy Policies of all the companies are not in compliance with DPDPA 2023 and some are not even updated after August 11th 2023 nor even under the CERT In guidelines.

Owners of Saafe seem to have co-interest in some FUPs .

I am sure that if I go through with all the 14+3 entities listed by RBI, every one of them may have some conflicting interest, lack of compliance to ITA 2000 or insufficient disclosure.

The system of AA licensing may be under equipped to meet the requirements of DPDPA 2023.

We are not aware if Meity will consider the sensitivity of information gathered by AAs as a criteria to classify them as Significant Data Fiduciaries when the rules are finalized. We have a feeling that the “Consent Manager” rules to be notified by MeitY can be a repetition of the RBI rules for AAs and hence all AAs will automatically be also recognized as Consent Managers.

Will Meity ignore the deficiencies in the AA licensing system and let AAs be completely under the sectoral regulation or subject them to the rigours of Significant Data Fiduciaries?

Let us wait and watch. If MeitY cannot resolve these turf related issues, they may chose not to release the draft rules and let things drift. We also need to watch whether the DPB does not get infiltrated with vested business interests.

Naavi

PS: It appears that more I look at the way AAs are being regulated now, I will be mentally disturbed. So I am stopping further exploration on this issue for some time. Assuming that RBI as well as the AA s are aware that there is now a law to catch up with and some body to watch what they are doing, we hope that they will take corrective steps themselves asap.

We may therefore wait and pray that responsible actions will be initiated by RBI soon. For the time being until the Ram Mandir in Ayodhya is inaugurated, Naavi.org would prefer not to raise such issues. Let us all spend time in saying Jai Shriram.

(This is a continuation of the previous article)

RBI has been a powerful sectoral regulator and has assumed leadership for regulating the entire financial sector including the FinTech companies. In the process, some of its regulations clash with the implementation of DPDPA 2023. It would be interesting to know how MeitY will proceed in the framing of rules regarding “Consent Manager” which has a direct conflict with the Account Aggregator licensing system that RBI has introduced and the Cross Border transfer of data.

Just as overlapping regulations between CERT-In and DPB affect Data Breach Notification, RBI regulations on Account aggregators have overlapping effect on the “Consent Manager” concept as well as the Data Fiduciary concept.

Account Aggregators are a category of licensed bodies from RBI as per the Master Directions of 2016. They may be referred to as NBFC-AAs by RBI. The list of NBFC-AA s licensed by RBI is not easily accessed on the RBI website. As of 30th October 2023, RBI website records that there are 12 registered AAs . However Sahamati.org.in lists the following AAs as of date.

Sr No	AA Company Name	Contact Person
1	Agya Technologies Private Limited	Nikhil Kumar contact@agya.co +91-98869-44331
2	CAMSFinServ	Tejinder Singh tejinder.singh@camsonline.com ‭+91-99672-32000‬
3	Cookiejar Technologies Private Limited (Product titled Finvu)	Manoj Alandkar info@cookiejar.co.in +91-70306-08902
4	CRIF Connect Private Limited	Kshitij Talwar +91-99104-06634 k.talwar@crif.com
5	Dashboard Account Aggregation Services Private Limited (Product titled Saafe)	Vijayan Rajasekar vijayan@saafe.in +91-80560-50532
6	Digio Internet Private Limited	Abhinav Parashar aa@digio.in +91-99459-58018
7	FinSec AA Solutions Private Limited (Product titled OneMoney)	A Krishna Prasad kp@onemoney.in +91-90300-98999
8	NESL Asset Data Limited (NADL)	Nirmal Sebastian nirmals@nadl.co.in +91-72590-20320
9	Protean (formerly NSDL E-Governance Account Aggregator Limited) (Product titled Protean SurakshAA)	Ranjit Saraf ranjits@proteantech.in +91-9769155240
10	Perfios Account Aggregation Services Pvt Ltd (Product titled Anumati)	Kantharaju H G kantharaju.hg@perfios-aa.com +91-94482-06567
11	PhonePe Technology Services Private Limited	Vidhi Jain aa@phonepe.com
12	Tally Account Aggregator Services Private Limited (Product titled TallyEdge)	Debashish Raut debashish.raut@tallysolutions.com +91-99717-35959
13	Unacores AA Solutions Private Limited (Product titled INK)	Ravi Doshi connect@ink-aa.com +91-98679-02913
14	Yodlee Finsoft Private Limited	Anuj Rai anuj@yodleefinsoft.com +91-95383-13081

AAs with In-Principle Approval

Account Aggregators which have received In-Principle approval from RBI are listed below.

Sr No	AA Company Name	Contact Person
1	Cygnet Account Aggregation Private Limited	Niraj Hutheesing niraj@cygnet-aa.com +91-98240-32919
2	OMS Fintech Account Aggregator Private Limited	Nitin Sawant nitin.sawant@omsaa.com +91-91453-54545
3	PB Financial Account Aggregator Private Limited	TBA

RBI in its Master Direction of 2016 has indicated certain criteria for registration of an entity as an Account Aggregator and obtain the Certificate of Registration.

Various conditions prescribed in the Master Directions include the following.

1. Entity must be a NBFC, registered as a “Company” with a net owned funds of a minimum of Rs 2 crores. (Registration under SEBI, IRDAI and PFRDA and restricting its activities to the sector is excluded from registration with RBI)
2. Initially an In-Principle approval would be provided and needs to be converted to a full registration within 12 months after setting up the technology platform.
3. Account Aggregator shall not undertake any other business other than the business of account aggregator. Deployment of investible surplus by an Account Aggregator in instruments, not for trading, shall however be permitted.
4. No financial asset related customer information pulled out by the Account Aggregator from the financial service providers should reside with the Account Aggregator.
5. Appropriate agreements are to be entered into between the AA and the customer.
6. The entity shall satisfy the “Fit” and “Proper” criteria for the proposed/existing directors

RBI has delegated the authority for managing the required architecture to REBiT. The technology architecture could be subject to an audit by REBiT

The NBFC-AA is envisaged to be a “Data Gateway” between a “FIU” or Financial Information User who needs certain financial information about an individual and one or more “FIP” s (Financial Information Providers” who may have that information .

Normally the individual (prospective client of the FIU) has to fetch the information from FIPs and provide it to the FIU. AA system tries to provide an alternative for a data exchange system which helps the Data Owner who is a customer of the AA and FIP and a prospective customer of the FIU.

In order to simplify this process, the Account Aggregator (AA) provides his service to the individual (Customer of AA). If the individual has an account with an AA, the information required by FIU can be re-directed to AA who in turn will fetch it from the FIP and provide it to the FIU. This entire mechanism needs to have a “Consent” framework which has been defined under the scheme.

The customer of an AA can be an individual or a non-individual. The Financial assets maintained by FIPs may therefore be personal or non personal information and FIUs may request for both types of information.

Where the requested information is related to an individual, the information becomes personal information under DPDPA 2023 and therefore needs to be compliant with the DPDPA 2023 requirements.

The RBI master direction has set a “Consent Artefact” as a standard format in which information has to be collected by the FIU from the Customer. This being a standard format can facilitate the data flow through the different participants such as the FIU, AA and the FIP.

The DPDPA is recognizing “Consent Manager” as a special kind of Data Fiduciary with all the obligations under DPDPA 2023 and the corresponding penalty possibilities. The legal basis for processing any personal data under DPDPA 2023 is “Consent” and hence there is a direct link between what a Consent Manager under DPDPA does and what the Consent Artefact under the AA framework represents.

We are yet to know the criteria to be fixed by MeitY for the Consent Managers under DPDPA 2023. It is presumed that there is already some pressure being brought upon Meity that all the entities already registered as Account Aggregators are to be considered as registered Consent Managers under DPDPA 2023.

The objective of our discussions is to debate if the activity of AA conform to the Consent Manager’s duties under DPDPA 2023 and whether the two services are similar. In the process we may be pointing out why the current functions of AAs as “Data Gateway Managers” do not fit into the requirements of Consent Managers under DPDPA who are Significant Data Fiduciaries.

For this purpose, apart from drawing the attention of the readers to the AA scheme as it exists now and integrated into the business of the 16 AA registered entities, we can explore the details of their operations to see if they are compliant with DPDPA 2023 as of today.

(To Be continued)

(Comments welcome)

Naavi