Re: Working paper - Using the DPV to map the GDPR Register of Processing Activities

Hi Beatriz, All.
I agree in principle the value of representing obligations, but I have 
concerns on how we specify them within DPV itself, and what it means for 
someone using DPV.

On 28/10/2020 16:16, wrote:

> IMO we should add the concept of obligations to DPV and specify the ones under GDPR on the DPV-GDPR vocabulary (similar to what I proposed for the data subject's rights).

We can - as and when we get consensus (and validation from a legal 
expert) on what the obligations are.
For a start, listing obligations out as concepts itself is tricky, and 
then further associating them with relevant concepts (e.g. purpose, 
legal basis) is complex.

> And, off course, the Register of Processing Activities should be one of the legal obligations of the data controllers & processors under the GDPR.

This is where there are differing views, and we need to be careful what 
we specify them as.
A concept (e.g. ROPA) vs an obligation (e.g. maintaining a ROPA) are 
semantically different.
Do we specify an obligation as a concept: MaintainROPA
or as a rule: isController(X) --> maintain(ROPA)

> In addition to ROPA, I would also like to propose the addition of the following obligations (some of them you already discuss on your paper):

Some of these (Joint Controller, DPIA) I think we already have as 
proposed. Some others are dependant on concepts that must first be 
present e.g. communication of data breach --> data breach.

Harshvardhan J. Pandit, Ph.D
Research Fellow
ADAPT Centre, Trinity College Dublin

Received on Wednesday, 28 October 2020 17:41:42 UTC