(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
