For a general overview of the Data Protection Vocabularies and Controls Community Group [[DPVCG]], its history, deliverables, and activities - refer to DPVCG Website.
The peer-reviewed article “Creating A Vocabulary for Data Privacy” presents a historical overview of the DPVCG, and describes the methodology and structure of the DPV along with describing its creation. An open-access version can be accessed here, here, and here.
Contributing to the DPV and its extensions The DPVCG welcomes participation regarding the DPV, including expansion or refinement of its terms, addressing open issues, and welcomes suggestions on their resolution or mitigation. For further information, please see the contribution section.
The Data Privacy Vocabulary (DPV) provides terms to annotate and categorise instances of legally compliant personal data handling. In particular, the vocabulary provides LegalBasis and DataSubjectRight as top-level concepts representing the various legal bases for justifying processing of personal data and rights provided to the data subject respectively. Since these concepts are specifically defined within the scope of jurisdictional laws, their implementation is provided as a separate vocabulary that extends the DPV, thereby permitting continued usage of DPV as a jurisdiction-agnostic and generic vocabulary.
DPV and DPV-GDPR only define the legal basis as concepts, and do not define or provide information associated with their validity. For example, determining whether consent is valid, or the appropriateness of a legal basis for its application in a use-case. The DPVCG is interested in providing such "helpful assistance" through semantics, and welcomes discussions and contributions for the same.
Valid consent in this case would have requirements for being 'explicit' in addition to requirements defined by A4-11. This is also mentioned in the Article 29 Working Party document "Guidelines on Consent under Regulation 2016/679 (wp259rev.01)"
Definition of consent: A data subject's unambigious/clear affirmative action that signifies an agreement to process their personal data (Rigo Wenning) . What is referred to as 'non-explicit consent' here is also termed as 'regular' consent in the Article 29 Working Party document "Guidelines on Consent under Regulation 2016/679 (wp259rev.01)". This is the legal basis that requires consent but not at the level of being 'explicit'.
Legal basis based on the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child
Legal basis based on the purposes of the legitimate interests pursued by the controller, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child
Legal basis based on the purposes of the legitimate interests pursued by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child
legitimate activities with appropriate safeguards by a foundation, association or any other not-for-profit body with a political, philosophical, religious or trade union aim and on condition that the processing relates solely to the members or to former members of the body or to persons who have regular contact with it in connection with its purposes and that the personal data are not disclosed outside that body without the consent of the data subjects;
preventive or occupational medicine, for the assessment of the working capacity of the employee, medical diagnosis, the provision of health or social care or treatment or the management of health or social care systems and services on the basis of Union or Member State law or pursuant to contract with a health professional and subject to the conditions and safeguards referred to in paragraph 3
An approved code of conduct pursuant to GDPR Article 40 together with binding and enforceable commitments of the controller or processor in the third country to apply the appropriate safeguards, including as regards individuals´ rights
An approved certification mechanism pursuant to GDPR Article 42 together with binding and enforceable commitments of the controller or processor in the third country to appy the appropriate safeguards, including as regards individuals` rights
The data subject has explicitly consented to the proposed transfer, after having been informed of the possible risks of such transfers for the data subject due to the absence of an adequacy decision and appropriate safeguards.
The transfer is made from a register which according to Union or Member State law is intended to provide information to the public in general or by any person who can demonstrate a legitimate interest, but only to the extent that the conditions laid down by Union or Member State law for consultation are fulfilled in the particular case.
The transfer is not repetetive, concerns only a limited number of data subjects, is necessary for the purposes of compelling legitimate interests pursued by controller which are not overridden by the interests or rights and freedoms of the data subject, and controller has assessed all the circumstances surrounding the data transfer and have on the basis of that assessment provided suitable safeguards with regard to the protection of personal data.
GDPR provides several rights to the data subject, whose applicability depends on the context and nature of processing taking place. DPV lists these rights at an abstract level as concepts along with their origin in specific clauses of the GDPR.
In addition to DPV's concepts regarding exercise of rights, DPV-GDPR provides additional concepts specific to the implementation of its rights. For example, [=SARNotice=] refers to the information provided in fulfilment of [=A15=] Right of Access, or using dcat:Resource to represent the dataset provided in fulfilment of [=A20=] Right to Data Portability.
A dataset or catalogue or any other resource provided in fulfilment of a Right Exercise, such as for GDPR's Art.15 regarding Right of Access or Art.20 regarding Right to Data Portability. The associated properties from DCAT and DCMI DCT vocabularies provide convenient means to express metadata such as URL for accessing the data, its temporal validity and acecss restrictions, and specific datasets present along with their schemas.
A Notice provided in fulfilment of GDPR's Art.19 regarding Recipients to whom a rights exercise has been communicated, such as regarding rectification (A.16) or erasure of personal data (A.17) or restriction of processing (A.18)
Harshvardhan J. Pandit
Data Transfer Tools
GDPR regulates data transfers outside the EU/EEA based on jurisdictions the transfer is occurring within and the guarantees available regarding the protection of personal data and fundamental rights. To indicate the sufficiency of a data transfer being compatible and adherent to these requirements, the European Commission provides various 'data transfer tools' based on the legal bases provided within the GDPR. DPV-GDPR models these as follows.
The DPV-GDPR's concepts for transfer tools are currently symbolic, and do not provide a way to actually implement those tools. For example, to represent the information contained within a SCC or BCR. The DPVCG is interested in providing such implementations, and welcomes discussions and contributions for the same.
Georg P Krog,
Harshvardhan J. Pandit
[[GDPR]] Article 35 specifies the conditions and requirements associated with Data Protection Impact Assessments. DPV-GDPR expands on the DPIA concept defined as an Organisational Measure within DPV by considering a DPIA as consisting of the following iterative process, and providing statuses for documenting their progression and outputs:
Identifying activities for which a DPIA is to be undertaken (represented using DPV and DPV-GDPR)
Checking whether a DPIA is needed as per GDPR Art.35 and other jurisdictional requirements: the activitiy is [=DPIANecessityAssessment=] and its output is denoted using [=DPIANecessityStatus=]
Conducting the DPIA to identify risks and impacts: the activity is [=DPIAProcedure=] and its output is denoted using [=DPIARiskStatus=]
Determining the outcome based on risk mitigation: the activity is [=DPIAOutcome=] and its output is denoted using [=DPIAOutcomeStatus=]
Determining whether processing should be permitted to continue or be carried out, with the outcome being denote using [=DPIAProcessingRecommendation=]
Assessing whether processing is carried out in conformance with the DPIA, with the outcome being denoted using [=DPIAConformity]
In addition to DPV's concepts for representing information about processing of personal data, DPV-GDPR also recommends using [[[DCT]]] concepts to represent relevant metadata, such as dates, identifiers, validity, etc.
The DPVCG is working on updating the [[[DPV-GUIDE-GDPR-DPIA]]] based on recent updates in DPV and DPV-GDPR. In addition to these, we are also working on providing concepts for expressing impacts and risk management within [[[RISK]]].
For expressing an existing standard, guideline, or requirements to which the DPIA document or process will be conforming to. This could be external guidelines published by an Authority, or internal guidelines established by the organisation
For expressing coverage (e.g. jurisdictions, products, services) of the DPIA document or process. For temporal coverage, please see dct:temporal. The coverage can be expressed using dpv:PersonalDataHandling, or using another concept, or even be a link or reference to a document, or a textual description
For expressing the temporal date or range of validity of the DPIA document or process. This refers to the time period for which the DPIA is considered valid, and does not refer to the temporal period associated with processing (see dct:temporal instead). The assumption is that after this period, the DPIA should be re-evaluated or some process should be triggered
For expressing the status of the DPIA document or process. Here different statuses are used to convey different contextual meanings. For example, dpv:ActivityStatus expresses the state of the activity in terms of whether it is ongoing or completed, and dpv:AuditStatus expresses the state of the audit process in terms of being required, approved, or rejected. These are applied over each step of the DPIA i.e. DPIANecessityAssessment, DPIAProcedure, and DPIAOutcome. Similarly, a process also uses hasStatus with DPIAConformity to indicate adherence to the results of the DPIA process.
left blank / unspecified
left blank / unspecified
The concepts in this section reflect the status of processing operations being in compliance with GDPR, by extending the ComplianceStatus from DPV for GDPR. It does not define the requirements for compliance itself.
The DPVCG and DPV were initiated as part of the SPECIAL H2020 Project, which received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No. 731601. The SPECIAL project ran over a 3-year period from 2017 to 2019.
Harshvardhan J. Pandit was funded by the Irish Research Council Government of Ireland Postdoctoral Fellowship Grant#GOIPD/2020/790 for working within the DPVCG and contributing to the DPV. The fellowship lasted from 2020 to 2022.
Funding Acknowledgements for Contributors
The contributions of Piero Bonatti and Luigi Sauro to the DPVCG have been funded by the European Union’s Horizon 2020 research and innovation programme under grant agreement N. 731601 (project SPECIAL) until 2019, and under grant agreement N. 883464 (project TRAPEZE) from 2020 until 2023.
The contributions of Beatriz Esteves have received funding through the PROTECT ITN Project from the European Union’s Horizon 2020 research and innovation programme under the Marie Skłodowska-Curie grant agreement No 813497.
The contributions of Harshvardhan J. Pandit have received funding from the ADAPT SFI Centre for Digital Media Technology is funded by Science Foundation Ireland through the SFI Research Centres Programme and is co-funded under the European Regional Development Fund (ERDF) through Grant#13/RC/2106 (2018 to 2020) and Grant#13/RC/2106_P2 (2021 onwards)
The following terms have been proposed for inclusion, and are under discussion. They are provided here for illustrative purposes and should not be considered as part of DPV.