@ -0,0 +1,40 @@ Justifications for Rights Exercising

This document outlines the identified concepts required to justify the exercising of data subject's rights, including justifications to delay or not fulfil such rights.

Overview

The motivation for this work is derived from the need to create and maintain records of the exercising of data subject's rights under the GDPR. This work was developed (and is already integrated) within the context of the DPVCG and was started with the main objectives of indicating

As such, the flows of information between a data subject and a data controller for the exercising of a right request, according to the GDPR, were analysed to extract the relevant concepts to be recorded. Figure 1 illustrates these flows.

After sending a notice to the data subject confirming that the request was received, the controller must be able to identify the data subject in order to proceed with the request (Article 12.2, second sentence). If the controller cannot identify the data subject, then the data subject must provide additional information to enable the controller to identify them (Article 11.2). If the controller disregards the request or has a justification for not fulfilling the right, then the data subject does not receive any information related to the right request (Article 12.2, second sentence). In case the controller has a justification to delay the request due to its complexity or a high number of requests, then the controller has a 2-month extension to fulfil its duty (Article 12.3, second sentence). Moreover, in case the request is unfounded or excessive, the controller can charge a fee and the data subject will get the information once this fee is paid (Article 12.5, first sentence). As it is visible by the diagram, at any point if the data controller does not fulfil its duty then a GDPR breach occurs and the data subject does not receive their requested information.

Flow diagram of GDPR data subject rights exercising
Flow diagram of GDPR data subject rights exercising, according to Article 12.

As will be explored in the next section, from the analysis of these flows of information, a set of high-level concepts was proposed and adopted by the DPVCG (general concepts on Rights are modelled in the main DPV specification at https://w3id.org/dpv#vocab-rights and GDPR-specific ones in the GDPR extension at https://w3id.org/dpv/legal/eu/gdpr#vocab-rights ).

Missing from these set of initial concepts adopted by the CG were terms to justify the fulfillment, non-fulfillment and delay in rights exercising. These shall be the main contribution presented in this document.

Concepts

This section highlights the concepts defined in DPV for the expression of information related to the exercising of data subject rights. In particular,

Base concepts

Core concepts of DPV's rights taxonomy
Core concepts of DPV's rights taxonomy

Beyond modelling concepts for applicable Rights and DataSubjectRights, to indicate the association of concepts with a particular right, the hasRight property is also modelled in DPV. Additionally, to make a distinction between actionable and non-actionable rights, the ActiveRight and PassiveRight concepts were created to distinguish between rights that require an action to be taken for them to be exercised and rights that don't require any action and are always applicable.

The isExercisedAt property should be used to connect a right with a RightExerciseNotice. This notice provides contextual information regarding how to exercise a right. Specialised notice concepts for rights that can be fulfilled and those that cannot are modelled as RightFulfilmentNotice and RightNonFulfilmentNotice, respectively.

To represent concrete records of rights being exercised, the RightExerciseRecord concept can be used to associate a particular request, or even distinct requests from the same data subject, with corresponding rights exercising activities, modelled as RightExerciseActivity, using the DCMI Metadata Terms hasPart property. Additionally, to track the status of rights exercising activities, a set of request statuses are modelled in DPV, including RequestAccepted for a request being accepted towards fulfilment, RequestRejected for a request being rejected towards non-fulfilment or RequestRequiresAction for a request requiring an action to be performed from another party. Figure 3 showcases the lifecycle of the request status defined in DPV.

Request status cycle to track the status of rights exercising activities
Request status cycle to track the status of rights exercising activities.

While this modelling was inspired by the GDPR, the concepts are described in a jurisdiction-agnostic manner so that they can be used to tackle data protection regulations in different jurisdictions.

Justifications

Justification concepts for the non-fulfillment, delay or exercise of rights.
Justification concepts for the non-fulfillment, delay or exercise of rights

A collection of justifications for the non-fulfillment, delay of fulfillment and exercise of rights were modelled as subclasses of the NonPerformanceJustification, DelayJustification and ExerciseJustification concepts.

The modelled concepts for each type of justification are defined below and the used GDPR clause is also introduced.

The following set of concepts can be used to reject a certain process or activity (NotRequiredJustification):

The following set of concepts can be used to express generic justifications for the non-fulfillment of rights exercising (RightNonFulfilmentJustification):

The following set of concepts can be used to express generic delay justifications for the exercising of rights (RightFulfilmentDelayJustification):

The following set of concepts can be used to express generic justifications for the exercising of rights (RightExerciseJustification):

Usage examples