This document provides additional details and examples for legal bases used in the Data Privacy Vocabulary [[DPV]], and is a companion to the [[DPV]] specification.

Contributing: The DPVCG welcomes participation to improve the DPV and associated resources, including expansion or refinement of concepts, requesting information and applications, and addressing open issues. See contributing guide for further information.

Introduction

DPV provides the following categories of legal bases based on [[GDPR]] Article 6: consent of the data subject, contract, compliance with legal obligation, protecting vital interests of individuals, legitimate interests, public interest, and official authorities. Though derived from GDPR, these concepts can be applied for other jurisdictions and general use-cases. The legal bases are represented by the concept [=LegalBasis=] and associated using the relation [=hasLegalBasis=].

When declaring a legal basis, it is important to denote under what law or jurisdiction that legal basis applies. For instance, using Consent as a legal basis has different obligations and requirements in EU (i.e. [[GDPR]]) as compared to other jurisdictions. Therefore, unless the information is to be implicitly interpreted through some specific legal lens or jurisdictional law, DPV recommends indicating the specific law or legal clause associated with the legal basis so as to scope its interpretation. This can be done using the relation hasJurisdiction or hasApplicableLaw . The list of available laws and their representation as extensions in DPV can be seen in the [[LEGAL]] extension.

Contract

[=Contract=] as a legal basis covers activities associated with creation of the contract ([=EnterIntoContract=]) and the performance of the contract [=ContractPerformance=]. Metadata associated with the contract such as date, time, subject, etc. can be represented using [[[DCT]]].

Contracts are also a `dpv:LegalMeasure` that can be used by organisations to enforce obligations e.g. by a controller on a processor. Similarly, contracts can also be 'agreements' e.g. between a controller and a processor, where the processor uses this agreement as a legal basis to process personal data.

Legal Obligation

[=LegalObligation=] represents using the justification of an obligation to perform the activity as defined in law or required by a legal procedure such as a court or authority order. When using legal obligations as the legal basis, it is good practice (and necessary for its legality) to also define the specific law or legal mechanism under which the obligation is defined. This can be done using `dpv:hasApplicableLaw`.

Consent

Consent is an important legal basis given its emphasis on individual empowerment and control, as well as the attention and relevance it receives from being part of direct interactions with individuals. Consent in DPV is a specific legal basis representing information associated with consent rather than only given consent. Common information associated with consent includes tasks such as keeping track of whether "consent has been given/obtained", "issuing a consent request", and "withdrawing consent", as well as expressing requirements through terms such as "informed" and "explicit". DPV provides concepts for representing information about how consent, as a legal basis, is utilised (by the Controller), provided or given (by the Data Subject), how long it is considered to be valid (its duration), and how it can be withdrawn. It also provides concepts related to management of information, such as keeping track of whether the consent has been requested, was refused, or has been given. This information can be utilised in applications associated with consent, such as creating a ‘record’ of consent or building and executing rules for compliance.

Given the reliance of consent as a legal basis whose validity is associated with requirements and obligations based on jurisdictional laws, DPV does not explicitly provide constraints on what should be considered a ‘valid’ consent. Instead, it focuses on providing declaration of information about consent so as to aid in the determination of its validity, and to record its use and changes over time. Further information concerning compliance obligations and requirements related to consent are considered within the scope of the DPVCG, and we welcome contributions on how this can be represented in a coherent manner that is compatible with the rest of DPV.

To assist with representing these concepts as well as keeping records about how they are being applied, DPV provides the following consent concepts.

• [=Consent=] - a type of legal basis representing consent of the individual.
• Consent Types - to represent criteria for consent, such as [=InformedConsent=] and [=ExplicitlyExpressedConsent=].
• Consent Status - to represent and keep track of what state/status/stage the consenting process is at, for example indicating the journey or lifecycle from [=ConsentRequested=] to [=ConsentGiven=] and then [=ConsentWithdrawn=].
• Consent Controls - to indicate information about how to obtain or provide or reaffirm consent.

To indicate the duration or validity of a given consent instance, the existing contextual relation `dpv:hasDuration` along with specific forms of `dpv:Duration` can be used. For example, to indicate consent is valid until a specific event such as account closure, the duration subtype `dpv:UntilEventDuration` can be used with additional instantiation or annotation to indicate more details about the event (in this case the closure of account). Similarly, `dpv:UntilTimeDuration` indicates validity until a specific time instance or timestamp (e.g. 31 December 2022), and `dpv:TemporalDuration` indicates a relative time duration (e.g. 6 months). To indicate validity without an end condition, `dpv:EndlessDuration` can be used. To indicate the notice used for informed consent, the concept `dpv:ConsentNotice` is provided, which can be used with the relation `dpv:hasNotice`.

To specify consent provided by delegation, such as in the case of a parent or guardian providing consent for/with a child, the `dpv:isIndicatedBy` relation can be used to associate the parent or guardian responsible for providing consent (or its affirmation). Since by default the consent is presumed to be provided by the individual, when such individuals are associated with their consent, i.e. through `dpv:hasDataSubject`, the additional information provided by `dpv:isIndicatedBy` can be considered redundant and is often omitted.

[=ConsentControl=] represents information about how to exercise a control regarding consent. To indicate how an organisation obtains consent, the concept [=ObtainConsent=] is provided. Its corresponding concept [=ProvideConsent=] specifies how a data subject can indicate their consent (decision). The concept [=ReaffirmConsent=] is used to indicate how to perform reaffirmation or confirmation of a previous control (e.g. provide or obtain consent). To associate consent controls, the relation [=hasConsentControl=] is provided. Consent controls are defined by extending relevant `dpv:EntityInvolvement` concepts `dpv:OptingIntoProcess` and `dpv:WithdrawingFromProcess`.

Legitimate Interest

[=LegitimateInterest=] represents a 'legitimate' reason for the entity to carry out an activity. This reason can be about benefits to the entity, or risks/harms to another entity. Where such benefits or risks/harms can be considered to be of 'vital interest', the legal basis [=VitalInterest=] should be used. Where this benefit or risks/harms pertains to the wider society or general public, the legal basis [=PublicInterest=] should be used. Legitimate interests can be associated with the controller, or data subject, or third party, or other entities. As good practice (and for their legality), the relevant entity must always be specified. We recommend using a relevant property such as `dpv:hasDataController` for data controller's legitimate interest to specify this. If a relevant property is not present in DPV, `dpv:hasEntity` can be used.

[=LegitimateInterestOfController=] represents a legitimate interest of the controller - such as carrying out `dpv:FraudPreventionDetection`. [=LegitimateInterestOfDataSubject=] represents a legitimate interest of the data subject - such as having a copy of the transaction (data or agreement) that it is providing or keeping their own records. [=LegitimateInterestOfThirdParty=] represents a legitimate interest of a third party - for example to investigate `dpv:CounterTerrorism` activities.

Official Authority of Controller

[=OfficialAuthorityOfController=] represents the legal basis where the official authority vested in the controller (by law) is used as the justification for carrying out activities. Such official authority is provided to specific departments to enable them to carry out their duties - such as maintainence of tax records, or provision of postal serviecs. The relevant law should be indicated as part of the legal basis if needed by using `dpv:hasApplicableLaw`.

Public Interest

[=PublicInterest=] represents activities carried out because they are 'in the interest of the general public' or are necessary to 'provide benefit to the public', where such benefit might be actual benefits (e.g. archiving data of cultural importance) or prevention of harms (e.g. identify relevant medical conditions quickly to prevent an outbreak). We strongly recommend providing a description of the relevant 'benefits' when using this legal basis e.g. by using `dpv:hasJustification` for contextual justifications associated with the benefit.

Protecting Vital Interests

[=VitalInterest=] represents activities that are necessary or required to protect vital interests of a data subject or other natural person. For more specific indication, [=VitalInterestOfNaturalPerson=] refers to vital interests of (any or a specific) natural person, and [=VitalInterestOfDataSubject=] represents vital interests of (any or a specific) data subject. As with [=PublicInterest=] and [=LegitimateInterest=], we strongly recommend specifying relevant information - the vital interest in this case - by using `dpv:hasJustification`.

Vocabulary Index

Contributors

The following people have contributed to this vocabulary. The names are ordered alphabetically. The affiliations are informative do not represent formal endorsements. Affiliations may be outdated. The list is generated automatically from the contributors listed for defined concepts.

• Arthit Suriyawongkul (ADAPT Centre, Trinity College Dublin)
• Axel Polleres (Vienna University of Economics and Business)
• Beatriz Esteves (IDLab, IMEC, Ghent University)
• Bud Bruegger (Unabhängige Landeszentrum für Datenschutz Schleswig-Holstein)
• Damien Desfontaines ()
• David Hickey (Dublin City University)
• Delaram Golpayegani (ADAPT Centre, Trinity College Dublin)
• Elmar Kiesling (Vienna University of Technology)
• Fajar Ekaputra (Vienna University of Technology)
• Georg P. Krog (Signatu AS)
• Harshvardhan J. Pandit (ADAPT Centre, Dublin City University)
• Javier Fernández (Vienna University of Economics and Business)
• Julian Flake (University of Koblenz)
• Mark Lizar (OpenConsent/Kantara Initiative)
• Maya Borges ()
• Paul Ryan (Uniphar PLC)
• Piero Bonatti (Università di Napoli Federico II)
• Rana Saniei (Universidad Politécnica de Madrid)
• Rob Brennan (University College Dublin)
• Rudy Jacob (Proximus)
• Simon Steyskal (Siemens)
• Steve Hickman ()