search

Informatievlaanderen / OSLOthema-consent

GitHub repository for the OSLO trajectory "consent"
0 stars 0 forks source link

The DataRequester is actually the DataController #9

Closed GeertThijs closed 2 years ago

GeertThijs commented 2 years ago

Description In both use case diagrams the Agents asking/getting Consent are (relation isProvidedToAgent) presented as DataRequesters are actually DataControllers. Both KBC and UZ Gent are the ones that "determine processing & purpose" of the data. Only when the Consent is a GivenConsent the processing can start, but at the moment of the request KBC and UZ already have determined that they want to do something with the data, providing they actually get the Consent. Also it is possible that no data is requested at all, for example that by using their website you agree terms & conditions without any data exchange. So, not everyone asking for Consent can be considered a DataRequester. Another issue here is that the term DataRequester is not used at all in the GDPR. There are other parties between the Controller and the Processor which are called ThirdParties (of which Recipient is a special case), but that's it. It would not be wise to introduce terms that are not mentioned in the GDPR, one could atmost consider to subclass DataController with DataRequester.

Solution Not use the term DataRequester but stay with the legal GDPR term DataController.

michaelgeamanu commented 2 years ago

After cross-checking with GDPR specialists and showing the changes in the 4rd thematic workshop, this issue has been closed with the solution proposed by Geert.