Data subject rights in practice
The rights concerned lead to various problems in practical implementation:
The right to data portability:
- leads in software with relational databases to the problem that too much data is exported and imported, this is often undesirable during export as well as during import, more about this in the following paragraph
- Data in relational databases are related to each other:
- Simplified example of a nursing service: a customer requests his digital data stock as an export with all master and transaction data to be assigned to him. From the patient table, the master data record is exported, for example, because this is related to the treatment table, the treatments are also exported and the treatments are linked to employees who are also exported.
- If the patient has his export data imported by another nursing service, the master data is created in the patient table, the treatments in the treatment table and the employees in the employee table (the employees from the old nursing service that exported). The importing nursing service does not want to have this employee data, because it has its own employees and the employees from the previous nursing service do not interest it, so it tries to delete them, but deletion is not possible because the employees are related to the treatments. The software provider then simply makes them invisible and does not actually delete them, since they are still related and can only be deleted when this relationship has been dissolved.
- For the export of his employee master data, the employee must at best be asked for consent for this data transfer or at least be informed about it.
Right to be forgotten
As I said, this is only a simple example, there are also document-based databases in addition to relational databases, such as e-mail software, where each e-mail is a document. We receive an application in the inbox of mailbox 1, since this is a central inbox, the e-mail is forwarded to the department coordinator of the department that has advertised the job, i.e. we have an outbox in mailbox 1 and thus already the first clone of our document, then the application is received in the mailbox of the department coordinator, i.e. a second clone of the application is created. The department coordinator forwards the email to the department manager, who distributes the application to the team leaders, all of them print out the application for a team meeting of the HR managers. They decide on the applicant and the department coordinator forwards the application to the works council for their OK. A deletion period of 6 months is agreed for application management, there are 20 clones of the original application + numerous offline copies circulating, the deletion period is only monitored in mailbox 1 inbox. The result is a process that can hardly be monitored and for which there are still no automated tools. Functional mailboxes offer a solution here, where applications arrive and result in a deletion-friendly workflow, or cloud services for applicants instead of emails. These are small examples of the real problem of implementing the rights of data subjects.