BackPrivacy checks can be built into software architecture
The job of data regulators can be eased by having a digital code enforce compliance with basic principles
PremiumIndia’s Data Empowerment and Protection Architecture (DEPA) has featured more than once in these pages. In a recent article, I explained how this framework makes it possible for us to split consent into collection consent (that we provide when we sign up for a service for the first time) and consent to port (that we provide just before data is transferred to a third party). This sort of bifurcation gives us more proximate control over what is done with our data, while at the same time reducing the complexity of the terms of service that we sign up to.
But DEPA can do so much more than just give us better control over our data transfers. It can establish a technological framework within which most—if not all—of the principles that underpin modern privacy legislation can be implemented in code.
Central to privacy laws anywhere in the world is a set of principles that define how personal data can be collected and processed. These include notice and consent (the obligation to obtain the informed consent of the data principal before collecting or processing her data), purpose limitation (the obligation to ensure that the purpose for which data is being collected is described in clear and specific terms), data minimization (the obligation to only collect as much data as is strictly necessary to achieve the stated purpose), retention limitation (the obligation to ensure that data is not retained for longer than required to achieve the stated purpose), and use limitation (the obligation to ensure that data is only used for the purpose for which it was collected). DEPA makes it possible for all these principles to be programatically achieved in relation to the transfer of data from one data fiduciary to another.
Let’s start with the principle of informed consent. DEPA uses the MeITy electronic consent artefact to process data-transfer requests. What this means is that each time a data fiduciary makes a request for data, it has to provide information on what specific data it needs, the purpose to which that data will be put, and the duration for which it will be retained for the same. As a result, every data transfer request will provide users with due notice and can only be completed if consent is provided in relation to that specific request.
Now let’s turn to purpose limitation and data minimization. Data-transfer requests under DEPA are template based: data fiduciaries will have to choose from a set of templates and pick the data request format that meets their requirements. These templates will be designed to cover a broad range of uses for which data might be requested, while still ensuring that only that much data as is necessary to fulfil those uses is requested. By using consent templates, DEPA programatically ensures that both the purpose limitation and data minimization principles are met.
As we can see, the basic DEPA construct addresses three out of the five privacy principles: Notice and consent, purpose limitation and data minimization. What it doesn’t seem to be capable of protecting is what happens to the data after it has been collected. In other words, there is nothing to prevent a data fiduciary from using the data for purposes other than those for which consent was obtained or from retaining it for longer than agreed in the data transfer request. If DEPA is to be an end-to-end solution for privacy, we have to incorporate technological safeguards that address the issues of use limitation and data retention as well.
In the recent past, advances in confidential computing have made hardware-based, trusted execution environments commercially available at scale.
Companies like Microsoft have started offering confidential compute solutions as part of their cloud service. Within these trusted environments, data can be processed in much the same way as it can while under the direct control of the processor. However, because this data never leaves the execution environment, the use of this infrastructure provides high levels of assurance on the integrity of the data being processed.
If we can use this technology to build confidential clean rooms and make them part of the standard DEPA implementation, we can, instead of transferring data into the control of a data fiduciary, deposit the data into these secure environs. The data fiduciary will be able to process data within the confidential clean room in much the same way as it currently does, with the added advantage of being able to ensure that processing is only limited to the stated purpose. In addition, this confidential clean room can be designed to extinguish data in accordance with the agreed data-retention policy. As is evident from this, the inclusion of confidential clean rooms in the DEPA construct would allow us to programatically implement the principles of use limitation and data minimization in its architecture.
Data protection authorities the world over have been struggling to exercise effective control over the data businesses they are supposed to regulate. Currently, the only tools at their disposal are the laws and regulations they are empowered to enforce. Of late, it has been getting increasingly clear that regulation simply cannot match the rate of change in technology. India’s Data Empowerment and Protection Architecture offers a technological solution that embeds privacy principles directly into the technology architecture. Done right, this might well be the solution that regulators have been looking for.
Rahul Matthan is a partner at Trilegal and also has a podcast by the name Ex Machina. His Twitter handle is @matthan
Unlock a world of Benefits! From insightful newsletters to real-time stock tracking, breaking news and a personalized newsfeed – it's all here, just a click away! Login Now!
