How ALIAS Approaches Tracking Personal Data Use

The ALIAS Events API facilitates the full tracking of how Personal Data is used in a system. It does this by providing a framework that allows “compliance as code” with an approach that parallels the “shift left” approach to catching defects and feedback loops of continuous integration and delivery found in DevOps and DevSecOps. Instead of siloing the tracking of Personal Data usage under the purview of the DPO, compliance with GDPR becomes part of the overall development and release process within an organization. We refer to this compliance with regulations as “DevRegOps”

In the ALIAS DevRegOps approach each piece of Personal Data is tracked and linked to a “GDPR Context,” which includes the history of manipulations and processing carried out on the data (including its collection). This history will provide the basis to prove the conformity with regulatory policies. In addition the records ALIAS retains provides the information necessary to comply with customer requests regarding their data as well as regulations regarding the duration that such data may be persisted.

Each modification of an element of a piece of data’s GDPR Context constitutes an “Event.” Systems must signal to ALIAS about the occurrences of various types of Events. For this purpose, clients of the API will be required to create “Sensors.”

Sensors are functions called each time an event occurs within the information systems of the company through hooks added into their source code or some other monitoring mechanism. The Sensors will signal to ALIAS that an interaction with a piece of Personal Data should be logged. This interaction can then be taken into account in computing the state of its GDPR context.

Developers using the ALIAS API will code Sensors to log events through the endpoints of the Event API. Events can be handled as they are triggered or recorded in batches. The parameters of these sensor implementations may differ depending on the type of event. However, every Sensor will have the common parameters of an ALIAS identifier for the data subject and the identifier of the event type that is being logged.

Customer data is tracked by events throughout the duration that company retains and uses that data. As example as to how this may look with real world system, consider the scenario depicted in the diagram below:

In this scenario, the Personal Data and its management by a hypothetical company starts with a form being filled out in WordPress hosted by OVH. This might be a form where an end user expresses interest in a product demo.

Later, a CRM application such as Zoho may send an email to that potential customer, which will use that data initially captured by the form.

After that individual has been contacted, they may elect to sign a contract, and again the Personal Data will be as part of that process.

Once the work agreed to as part of that contract has been done for this customer, they will be invoiced by another application such as Sage.

Later the customer may request that their data be removed, after which it must not only be removed from our hypothetical company, but it must also be removed from Zoho (the CRM) and any other 3rd parties by which it was used.

However, some of that data may need to be retained for the purpose of the company’s own compliance with financial regulations. At this point the fact the data is being retained in certain systems must be recorded along with the justification for doing so while it must be removed from all others.

At each stage in this process an Event will be created and logged with Alias via a Sensor, helping the DPO of the company accurately maintain processing records for that data. This information will be relevant to the length of time the data may be retained. For instance, if instead of responding to the email sent by our hypothetical company, the end user had instead chosen to ignore it. After a certain duration, our hypothetical company would have been obligated to remove the data for this potential lead from their system because the duration that they were legally allowed to retain it had expired.

It is the sort of events described above for which developers will need to implement sensors that capture them as they occur and log them through the ALIAS Events API.