When looking at the GDPR requirements, I see four conditions that we can put in the app design by default. In user stories, they would look something like this:
- As an end-customer, I can request the company to create a computer-readable dataset of all my (personal)data to facilitate switching to another (service)supplier. (In GRPR language: the right to access. Art. 12 GDPR Transparent information, communication and modalities for the exercise of the rights of the data subject Art. 15 GDPR Right of access by the data subject Art. 46 GDPR Transfers subject to appropriate safeguards)
- As an end-customer, I can request the company to delete all my personal data so that no personal information is stored in a system. (In GDPR language: the right to be forgotten. Art. 17 GDPR Right to erasure (‘right to be forgotten’) Art. 19 GDPR Notification obligation regarding rectification or erasure of personal data or restriction of processing)
- As an end-customer, I can request the company to reduce all personal data to a minimum required to fulfil the company's primary function. (In GDPR language: data minimalisation to support only the companies primary purpose. Art. 5.1.b and c)
- As an end user, I will be actively informed on the personal data that is is going to be/being processed for me to judge if the service/product suits me. (In GDPR language the right to be informed. Art. 12 GDPR Transparent information, communication and modalities for the exercise of the rights of the data subject Art. 13 GDPR Information to be provided where personal data are collected from the data subject Art. 14 GDPR Information to be provided where personal data have not been obtained from the data subject)
The domain model design should anticipate on these (and even maybe other) requirements. So if we create a customer Entity, we should separate the minimised data for the primary function from the other data we would like to process (with customers consensus).
I’m thinking of the Entity “Customer” and an Entity “CustomerGDPRMin”. Doing this will separate the data required for the primary function of the company from the other data. So, other Entities servicing the primary function can have a relation to “Customers” but not to “CustomerGDPRMin”. An invoice for the service can use the customer data in “Customer” but not in “CustomerGDPRMin”. When the end-customer asker for data minimalisation it is just a matter of deleting customer rows in the “CustomerGDPRMin” table. The advantage will be:
- Simple deletion logic
- Preventing data not being deleted because of referrals in other parts of the system (depending on settings)
- Creating functional inconsistencies
The marketing department can still access the data in “CustomerGDPRMin” when available. Since a picture is telling more than words...
To keep track of personal data, it would be nice (feature request) that in the properties of an attribute of an entity we could add a label or set a flag. This labelling, would help to (automatically) generate a query for user-story 1. Until this feature will be realised the best way to keep track is storing the personal related data in the attributes of a GDPR entity.
Who would be willing to help in the creation of a GDPR Mendix example?
Would it be fun to create such an example together and make it available to all?
- Table examples
- Auto query generator for the use cases
- Default screens for GDPR requests
- Default process for GDPR request handling (like identifying the requestor as being the data subject and so on)
- Optional billing, invoicing and collection of the fee’s that are allowed to get for the service