“Role based Data Access Management” (RBDAM) is a common principle in Data Access Management. In a properly structured RBDAM, access permissions to data is configured based on the functional role of an individual rather than an administrative designation such as “Manager” or “Vice President” etc.
However for an efficient management of DPDPA responsibilities, it is essential that the “Personal Data Access” is restricted to those who manage the process related to the “Purpose” for which a “Consent” has been provided by a Data Principal”.
“Role” in this context should mean “Purpose” of processing. The “Purpose” is closely linked to “Consent” except in the cases where “Legitimate use” or “Exemption” is used as the legal basis for processing. Hence Role Based Data Access Control (RBDAC) should mean “Purpose Based Data Access Control” (PBDAC). This concept is better understood if we term it as “Consent based Data Access System”. In the case of Legitimate Use or Exemption based process, the “Consent” is from the legal department or top management of the Company which the process owner may still consider it as “Consent as far as he/she is concerned”.
Constructing PBDAC
Personal Data in an organization originates for two basic purposes namely “Marketing” and “HR”. Means of processing may be functionally managed by the IT team assigned with the processing of Data. DPDPA recognizes “Data Fiduciary” status based on the determination of “Purpose and Means” and some times this responsibility may be shared by multiple organizations who may be all Joint Data Fiduciaries.
The means of obtaining the Personal Data required for HR is directly handled by them as a part of the recruitment process. The collection may however be predominantly handled through external agencies for short listing of candidates or Background verification. Independent Background verifying agencies may be “Joint Data Fiduciaries” in most cases.
The means of obtaining Personal Data for Marketing is mostly dictated by the Technology of scrapping the information from different sources, processing them for profiling the people behind the information before they are converted into “Identified Target for Advertising”. The means of such collection is often driven by the R&D or Data Analytics departments in the organization.
Many other departments of a Company such as Finance or Purchase etc handle personal data of a different kind namely “Business Contact Data” where the information is declared as usable for Business Contact. Whether “Business Contact” is a purpose similar to “Marketing” or “HR” or is to be considered as “Not Personal Data” in DPDPA sense which originates from the concept of “Privacy as a human Right” as is a moot point. We shall leave this discussion to another day.
In order to set up a Data Access System based on “Roles” and be also compliant with DPDPA, we need to understand that “Roles” are not related to “Administrative Roles” such as Chairman, MD, VP, GM etc.. Nor such roles should be indirectly recognized with a hierarchy of CEO, CTO, CFO,CMO etc.
For effective DPDPA Compliance, the role definitions should be recognized at a more granular level. For example, if CxO s are policy makers, they donot need access to “Identified Personal Data” but only “Categorized and grouped data”. The CEO therefore need not have access to identified personal data with the organization except of the group of CxOs that he directly monitors. The CEO log-in to corporate data base need not therefore have access to the customer data handled by marketing department nor the personal data of all employees.
If the CEO has limited access to identified personal data, the possibility of data breach through his laptop or mobile being compromised or lost is lesser.
In evolved organizations, this “Modified Role Definition” delinking the administrative role may be already in practice at least at one level. Accordingly, a security analyst may configure a firewall but may not be able to view customer data, while a sales rep can see customer data but can’t touch firewall settings.
However this discretion may or may not be carried through to the level of the CEO or Directors who may be having a complete access to the system by default even though they may not have time or inclination to use such an access. Similarly, the “Admin” may some times have access to all identified personal data at the granular level though he has no need to access them.
The challenge therefore is to identify a set of personal data, associate it with a “Purpose” for which it is being processed in the organization and provide access only to such persons who need to carry out the purpose. Every body else should be shut off by default though they may be given access on request from time to time for a specified purpose.
Some companies may have taken a re-look at the corporate designations themselves avoiding the traditional designations such as VP, GM etc and use a technology oriented designation such as a “Process Head” or “Process Group Head” etc. This could be adopted by others also as it clarifies in the designation itself the “Purpose”.
Under DGPSI, (Data Governance and Protection Standard of India) it is suggested that an organization’s business is broken up into multiple “Processes” and each process is assigned a “Purpose”. Any personal data which the “Purpose” requires is provided access through a gateway open only to that purpose. All the workforce who are required to process the data for that purpose need to be provided access through the single gateway so that they will get access to only such data that are part of the process.
It is possible that the “Data Store” may contain all sets of “Personal Data” and each set of personal data may contain several personal data parameters all of which are not required for one process. In such cases the process handlers are expected to have access only to the parameters of personal data required for fulfilling the purpose. Hence instead of giving the access to “Data of Mr X” , access is given only to “Part of the Data of Mr X” that is relevant for the purpose.
This architecture requires a “Personal Data Store” with “Groups of Data Elements in each personal data set” being identified with a “Purpose/Process tag”. Such sub groups will have their own “Consents” from the data principals with specific conditionalities which need to be monitored separately. The Personal Data set identity has to therefore be configured with an ability to allocate sub identities for the sub groups each of which is assigned to a purpose.
Ultimately the “Role Based Access” has to recognise that the “Role is linked to the Purpose specific process” and use the “Consent” as the basis for defining the “Role Based Access”.
In the processing of “Personal Data”, it is the Data Principal who provides consent for a “Purpose”. The IT team structures the system for a specific “Process” to meet the requirement of the “Purpose”. Access can only be provided to those people ( or AI Agents) who need to have access.
The “Role Based Access System” therefore needs to be structured along with a compatible Data Storage system and Data Parameter tagging system. The Access control is jointly managed by the Data Principal” and the IT team along with the Process manager and HR team.
I hope technology tool creators keep this DGPSI principle of “Process Based Organizational Data Structure” in mind when they design the architecture for Personal Data Storage and access.
(PS: I have tried to present here a complicated thought on technical architecture of a Personal Data Management system. I wish I could have provided better clarity. Hopefully, I will be able to expand this thought in a different forum. )
Naavi
