We've finally all arrived in the age of GDPR, BDSG, and, in Switzerland, DSG, DSV, and VDSZ.
I will summarily refer to all of these legal constructs as GDPR in this article.
Their goal is that any person having given their data to a company or other legal entity can request that their data is reported to them or even removed.
So, as a designer of processes, you have to make facilities available in your applications to report and anonymize or remove personal data stored in your processes.
With process applications, there are a few things that need to be considered when designing these facilities:
- it is a good idea to prevent gathering unnecessary data.
- Anonymization or deletion of personal data cannot occur in running processes, if the recorded data is crucial. You need to abort these processes if the person requests immediate removal of personal data.
- You need to determine what data needs to be retained in terminated processes - whether they are completed or aborted.
- You need to be able to report back user personal data upon request.
Since Axon Ivy allows you to add custom fields to business cases, cases and tasks, it is not possible for Axon Ivy to determine which fields are candidates for personal data which may need anonymization. Therefore, Axon Ivy does not offer an out-of-the-box GDPR compliance solution.
However, in an effort to provide Axon Ivy Developers with the tools necessary to provide parts of the required solutions, we published our database schema in the documentation since version 10.0. It is the tool to identify what needs to be anonymized or removed.
We work with internal IDs most of the time. As an example, you will not need to remove the user ID from a process, but you will need to make sure that the name, address, e-mail address and other data is removed from the user record.
However, names may have been entered into text fields - so, you need to devise
- a policy on personal data identification, data retention, anonymization, and removal
- a standard defining what is considered personal data, and
- procedures defining how to cope with identified personal data
- procedures on how to honor requests to report or delete a user's personal data
Note that the procedures may not only define what you as a developer need to do, but also how users of your application have to process data - "never record names", "addresses need to be added to the user, not in text fields", or how to handle process flows etc.
