Implications of using SKOS vs OWL

<p>This example highlights the implications of using DPV with RDFS+SKOS and OWL semantics. The RDFS+SKOS model is suitable for when DPV concepts have to be used 'directly' e.g. an use-case wants to use 'Encryption' from DPV as a technical measure without creating a specific 'instance' representing their implementation of the encryption. RDFS+SKOS model is also suitable for when an use-case wants to further create an hierarchical taxonomy of the different 'Encryption' concepts they are using. Such use of DPV concepts covers both T-box and A-box, and does not restrict or require the underlying ontology/schema to be constantly changed as new concepts are identified in an use-case.</p>
<p>In comparison, the OWL2 model defines concepts as classes and instances with a clear separation between the two i.e. the Tbox and Abox are separate. This means the concept 'Encryption' cannot be directly used with OWL2 semantics and an instance of it must first be created. If instead DPV had provided 'Encryption' as an instance (of Technical Measure) then the further expansion and creation of a hierarchy of encryption concepts described earlier is not feasible in OWL2 as it results in a complex graph which is not efficient for reasoning. Further, making changes such as promoting 'Encryption' from instance to class requires changing the ontology/schema - which may not always be possible or feasible in use-cases.</p>
<p>Thus, the relative strengths and weaknesses of RDFS+SKOS and OWL2 serialisations dictate which should be used. RDFS+SKOS is 'lightweight' and better if the use-case only requires rudimentary or simple reasoning. OWL2 is better suited for semantic reasoners that can perform complex discovery and validation processes but require more strict and restricted use of concepts. By providing both serialisations, DPV enables the adopters to choose the most suitable serialisation that supports their use-case and/or existing implementations, and retains semantic interoperability based on converting between SKOS and OWL2 (see <a href="https://www.w3.org/2006/07/SWD/SKOS/skos-and-owl/master.html">Using OWL and SKOS (2008)</a>).</p>

Harshvardhan J. Pandit

Extending concepts to represent use-case specific information

<p>DPV defines the (broad) concept of <a href="https://w3id.org/dpv#Marketing"><code>Marketing</code></a> in its <code>Purpose</code> hierarchy to represent information about (purposes related to) marketing activities and topics. For a use-case which requires representing purposes (note: plural) related to <i>marketing of new products</i>, the broad <code>Marketing</code> concept is extended as a <i>child</i> or <i>subclass</i> concept for representing the intended purpose as, e.g. <code>MarketingNewProducts</code>.</p>
<p><strong>Note:</strong> Here the prefix <code>ex:</code> represents <code>http://example.com#</code> - which is a convention for representing additional examples or concepts, such as those created as part of the use-case. The rest of the document follows this nomenclature and convention.</p>

Harshvardhan J. Pandit

Extending multiple concepts

<p>For example, two TV companies (<code>AliceCo</code> and <code>BobCo</code>) extend the concept <code>Optimisation</code> to reflect their respective purposes. When exchanging information about their use-cases with each other (or with a third party), by following the chain of use-case specific concepts it is possible to deduce that both <code>AliceCo</code> and <code>BobCo</code> are doing optimisations for consumers. Thus a common language or interface can be developed based on using DPV as a point of interoperability and commonality which can be used by adopters to define the specifics of their use-case. For example, in the above use-case, a common notice generation algorithm could be created and used to inform users of both services the purposes each company is using data for.</p>

Harshvardhan J. Pandit

Interoperability of extended concepts across use-cases

<p>For example, two TV companies (<code>AliceCo</code> and <code>BobCo</code>) extend the concept <code>Optimisation</code> to reflect their respective purposes as follows:</p>

Harshvardhan J. Pandit

Process used to combine core concepts and represent an use-case

<p>An example of how <code>Process</code> brings together the core concepts, consider the example where <code>Acme</code> is a <code>DataController</code> that <code>Collect</code>(s) and <code>Use</code>(s) <code>Email</code> for <code>ServiceProvision</code>. Note that the <code>pd:EmailAddress</code> is a concept from the [[[PD]]] extension.</p>

Harshvardhan J. Pandit

<p>Consider the example where <em>Acme</em>, as a <em>DataController</em>, maintains records of its processing activities using <code>Process</code> to represent one of its services. In this, it collects email, uses it for internal analyses based on <em>Legitimate Interests</em>, and also sends marketing information by using a processor based on the data subject's consent. Using nesting of processes, the information can be expressed at a granular level representing service, individual purposes, and so on.</p>

Harshvardhan J. Pandit

Extending Purposes and adding human-readable descriptions

<p>In this example, a new purpose is created by extending <code>dpv:FraudPreventionAndDetection</code> and annotated with human-readable information. The interpretation of this purpose is thus more clear in relation to how it is applied or used within that use-case, and also serves to compare it with other purposes within the same category.</p>

Harshvardhan J. Pandit

Using NACE codes to restrict Purposes

For example, the following purpose concerns implementing access control with the domain specified as scientific research using its corresponding NACE code <code>M72</code> to indicate sectorial implications for what "access control" and "enforce security" are expected to imply.

Harshvardhan J. Pandit

Derivation and inference of personal data

<p>This use-case collects browser fingerprint and IP Address to identify the country one is visiting from, and to infer language to be used for personalisation. Note that this example uses [[PD]] for personal data concepts.</p>

dpv:Derive,dpv:Infer,dpv:DerivedPersonalData,dpv:InferredPersonalData

Harshvardhan J. Pandit

Indicating personal data is sensitive or special category

<p>In a medical study involving genetic data, the person's collected blood samples are considered to be 'special category' personal data under the GDPR. In addition to this, the person's identifier associated with that dataset to enable monitoring future appointments is considered sensitive within the medical centre. Note that the examples use the [[PD]] extension to represent some concepts.</p>
<p>In this example, the knowledge that blood samples are of type 'special category' can be inferred from the fact that they are a form of <i>Medical Health</i> which is a 'special category'. However, the example considers best practices that suggest explicitly identifying and denoting that blood samples are also of type 'special category'.</p>

dpv:SensitivePersonalData,dpv:SpecialCategoryPersonalData

Harshvardhan J. Pandit

Indicating Storage Conditions

<p>This example includes Acme as a Data Processor that stores data within servers located in Ireland for a period of one year. The temporal information is represented using [[[TIME]]], and the location is specified using [[[LOC]]].</p><p>In this example, the <code>StorageCondition</code> is expressed as a separate policy applicable. It is also possible to directly express it over other concepts such as a service, technology, or a processing operation, e.g. to say <code>ex:AcmeStore dpv:hasStorageCondition ...</code>.</p>

dpv:StorageCondition

Harshvardhan J. Pandit

Indicating Data Sources

<p>Data sources can be the data subject (direct or indirect), the data controller or processor (itself), or another entity (third party). The below example provides an overview of these with distinctions between source and method of generation.</p>
<p>In this example, <code>ex:S01</code> represents direct collection of data from the data subject, while <code>ex:S02</code> represents indirect collection where data is derived or observed - or undergoes any operation that still points to the data subject as the source. <code>ex:S03</code> infers data, which means the inferring entity (the Controller in this case) is the source of this data - even if the inferred data is based on data collected from the Data Subject. <code>ex:S04</code> has data sourced from another entity - such as a Third Party, but could also refer to a Data Processor. <code>ex:S05</code> represents collection of data from a public dataset that has been published by the data subject themselves.</p>
<p>Note that the above example is illustrative - it may be pertinent to provide documentation about each data source to ensure sufficient information is recorded for intended purposes. For example, the method of collection (e.g. forms), or inference (e.g. algorithm), or public dataset (e.g. link, license).</p>

dpv:DataSource

Harshvardhan J. Pandit

Spam filter as Automated Decision Making with Human Involvement

<p>Consider the use of a spam filter that is based on automated processing operations where humans provide inputs, have oversight of the operation, and results in automated decision making for whether communications should be propagated. A new separate filter is developed that utilises a novel spam detection criteria that also takes into account communications other than emails for the sender and makes automated decisions whether to permit communication to proceed. Such explicit annotation of several high-risk operations assists in performing impact assessments for this technology, as well as understanding the extent and effectiveness of human involvement to mitigate risks and issues.</p>
<p>In this example, the Spam Filter process allows the users to reverse the effects (i.e. emails marked as spam) but does not allow opting out from the process (i.e. stop spam filtering). The spam detection algorithm performs automated decision making (by deciding which emails to accept), systemic monitoring (of communications), and evaluation and scoring (by scoring contents of emails and senders/recipients). The spam detection algorithm also indicates what human involvement is expected - to provide input (e.g. mark emails as spam) and intervention (e.g. change spam criteria).</p>

dpv:AutomationLevel,dpv:HumanInvolvement

Harshvardhan J. Pandit

Denoting Legal Basis within a Process

<p>The <code>LegalBasis</code> can be associated with any concept using the relation <code>hasLegalBasis</code>. Such associations are of three types: (1) where the legal basis refers to an instance, such as the consent or contract associated with a particular data subject; (2) where the legal basis refers to the category that will be used to justify processing, such as the concept <i>consent</i> to denote consent will be the basis for indicated processing; and lastly (3) where the legal basis is defined with a context, such as <i>consent of service consumers</i>.</p>

dpv:LegalBasis

Harshvardhan J. Pandit

Indicating consent as a legal basis

<p>Here, a process instance represents some context (e.g. a service, or a product, or some operation), and the example specifies that the legal basis for these is the use of consent.</p>

Harshvardhan J. Pandit

Indicating details about an individual's consent

<p>In this example, an individual's consent is recorded with abstraction in the form of linking to a common process instance from the previous example. This 'common' process represents processing taking place for all data subjects, whereas the consent instance refers only to the individual with a link to this common information. This is to present an alternative method for storing information as compared to extensive consent records.</p>

dpv:ConsentRecord

Harshvardhan J. Pandit

Representing notice, provision, expiry, and withdrawal information for consent

This example first specifies a privacy notice as a document is being used in the context of a service as represented using a personal data handling instance. Then it provides an alternative representation where the contents of a notice are described using DPV.

dpv:Notice,dpv:PrivacyNotice

Harshvardhan J. Pandit

This example shows use of DPV consent types to distinguish between 'expressed' and 'explicitly expressed' consent

dpv:Consent,dpv:ExpressedConsent,dpv:ExplicitlyExpressedConsent

Harshvardhan J. Pandit

Indicating Entity Information, including DPO and Representatives

This example shows how information about representatives can be associated with an entity

dpv:Representative,dpv:DPO

Harshvardhan J. Pandit

Using technical measure: Protecting data using encryption and access control

<p>To indicate data is encrypted using the <a href="https://en.wikipedia.org/wiki/RSA_(cryptosystem)">Rivest-Shamir-Adleman (RSA) method</a>, one would extend the <a href="https://w3id.org/dpv#Encryption"><code>Encryption</code></a> concept within DPV to represent <code>RSA</code>, and then instantiate it with the specific implementation used (e.g. to indicate key size). Access to this data is further restricted by requiring a password or credential.</p>

dpv:TechnicalMeasure,dpv:Encryption,dpv:AccessControlMethod

Harshvardhan J. Pandit

Using organisational measure: Indicating staff training for use of Credentials

<p>To indicate staff are trained in the use of credentials, and that a policy exists regarding this, the use of <code>OrganisationalMeasure</code> concepts can be combined in several ways. Note that the interpretations for how staff training is associated with credentials, or contains training regarding credentials is arbitrary in notation. It is intended to demonstrate how different perspectives can be represented so as to be suitable to the organisation's documentation practices.</p>

dpv:OrganisationalMeasure,dpv:StaffTraining

Harshvardhan J. Pandit

Privacy Notice used in an activity

<p>This example first specifies a privacy notice as a document is being used in the context of a service as represented using a process instance. Then it provides an alternative representation where the contents of a notice are described using DPV.</p>

dpv:PrivacyNotice

Harshvardhan J. Pandit

Consent record example

<p>This (simplified) example shows a consent record containing the topic of consent (i.e. which processing activities it was about), its current status, and when it was given by the data subject. The structure of a record is highly dependent on the requirements of the use-case, and can vary across implementations. In this case, it is based on the ISO/IEC TS 27560:2023 Privacy technologies — Consent record information structure, for which we provide the implementation guide [[[GUIDE-Consent-27560]]].</p><p>The example uses the <a href="https://dublincore.org/specifications/dublin-core/dcmi-terms/">DCMI Metadata Terms (dct)</a> vocabulary to indicate metadata such as title and timestamps. Other vocabularies such as <a href="https://www.w3.org/TR/prov-o/">PROV-O</a> can be used to also indicate provenance information such as when it was generated and how it was produced.</p>

dpv:ConsentRecord

Harshvardhan J. Pandit

Controller-Processor agreement denoting processing to be carried out

<p>Acme is the Data Controller that contracts BetaInc as a Data Processor to analyse raw call logs and provide statistical patterns.</p>

dpv:ControllerProcessorAgreement

Harshvardhan J. Pandit

Data transfer safeguards

<p>This example represents a contractual agreement between a controller and a processor indicating the use of encryption and EU commission approved Standard Contractual Clauses as specific measures to safeguard data transfers between them.</p>

dpv:DataTransferSafeguard

Harshvardhan J. Pandit

Example of Contextual Necessity

<p>In this example, a <code>Process</code> instance consists of two nested <code>Process</code> instances for each of the optional and required parts. The personal data category 'Account Identifier' is indicated as being required for 'Communication for Customer Care', while the use of 'Email' is optional for the same purpose.</p>

dpv:Necessity

Harshvardhan J. Pandit

Indicating risks, consequences, and impacts

<p>In this example, we consider <i>Risk</i> can be associated with any concept given its broad existence and applicability, and that its mitigation is a technical and organisational measure. Using this, the implemented or adopted technical and organisational measures within an use-case are annotated with the risks they address or mitigate, along with specific impacts that may occur if the risk were to occur. For example, the storage of personal data within a database has an implementation of access control that mitigates the consequence of unauthorised access and its impact to cause harm.</p>

dpv:Risk,dpv:Consequence,dpv:Impact

Harshvardhan J. Pandit

Rule specifying permission

<p>In this example, a Process which consists of using an email address for service provision using the legal basis as Consent is permitted</p>

dpv:Permission

Harshvardhan J. Pandit

Rule specifying prohibition

<p>In this example, the hasProhibition relation is directly used to assert a prohibition to handle Health data within a Process:</p>

dpv:Prohibition

Harshvardhan J. Pandit

Rule combining DPV with ODRL

<p>In this example, DPV is complemented with ODRL, following the ODRL implementation best practices, to assert an obligation to Anonymise data in order to use it:</p>

Harshvardhan J. Pandit

Using Service to group related processes

This example shows the use of Service concept to represent a 'service' provided by an organisation, which includes two processes for data collection and service provision

dpv:Service,dpv:Process

Harshvardhan J. Pandit

Indicating Controller identity and details of representative

This example describes a controller with details for name, address, and contact, and its representatives for EU and US jurisdictions

dpv:DataController,dpv:Representative

Harshvardhan J. Pandit

Indicating Processor as the implementing entity in a process

This example shows a process with its controller and processor, and the explicit statement for the processor doing the collection and storing of personal data

dpv:DataController,dpv:DataProcessor

Harshvardhan J. Pandit

Specifying recipients of data

This example first shows a process where the processor is denoted as the data recipient, and then another process where a third party is denoted as the recipient. A joint controller agreement is then shown which specifies that only one of the controllers involved is a data recipient.

dpv:DataRecipient

Harshvardhan J. Pandit

Specifying data exporters and importers

This example shows how data exporters and importers for a transfer can be indicated using DPV. It also shows how the locations associated with exporters and importers are relevant to determine cross-border transfers.

dpv:DataImporter,dpv:DataExporter,dpv:Transfer

Harshvardhan J. Pandit

Indicate relevant authority for processing

This example shows how a DPA can be associated with processing, and the use of LEGAL extensions to obtain DPA information. It also shows how DPAs can be 'discovered' by using the location (jurisdiction) and applicable law concepts.

dpv:DataProtectionAuthority

Harshvardhan J. Pandit

Indicating type of organisation and involvement of specific organisational units

This example involves an organisation that is a NGO, and that it has Marketing, HR, and IT departments. The HR and IT departments are responsible for specific processes.

dpv:OrganisationalUnit,dpv:isImplementedByEntity

Harshvardhan J. Pandit

Indicating subsidiaries of an organisation

This example shows the existence of two subsidiaries associated with an organisation and their locations

dpv:Subsidiary,dpv:hasSubsidiary,dpv:isSubsidiaryFor

Harshvardhan J. Pandit

Indicating involvement of data subjects

This example shows the different ways in which data subjects can be indicated in a process. It also shows how the DPV taxonomy of data subjects can be used to combine concepts to accurately represent the data subject involved. And it also shows how information associated with specific data subjects such as identifiers can be indicated.

Harshvardhan J. Pandit

Extending a purpose and using human-readable descriptions

This example describes how a purpose can be made clearer and accurate by two methods: (1) providing a human-readable description - which is always recommended; and (2) by extending a DPV concept

Harshvardhan J. Pandit

Indicating purposes associated with a Service

This example describes how the different purposes and information associated with a service can be expressed in a modular and clear manner

dpv:Purpose,dpv:Service,dpv:Process

Harshvardhan J. Pandit

Indicating legal compliance as a purpose along with the relevant law

This example describes a purpose for performing 'KYC' identity verification as part of legal compliance with anti-money laundering laws

dpv:Purpose,dpv:LegalObligation

Harshvardhan J. Pandit

Indicating sector or domain and associating it with a purpose

This example uses the NACE taxonomy to indicate the domain or sectorial relevance of the purpose

dpv:Purpose,dpv:Sector

Harshvardhan J. Pandit

This example shows how personal data can be specified by for a work email address in four methods: (1) by using the PD taxonomy, (2) extending a concept from PD taxonomy,(3) specifying the exact value of email address, and (4) using external vocabularies such as schema.org. In all of these, it is strongly recommended to include a DPV concept (i.e. declare it as Personal Data) for interoperability, and to align it with the DPV and PD taxonomies where relevant (e.g. to mention it is an email address, or to specify it is identifier, or that it is sensitive - which it is not in this case)

dpv:PersonalData,dpv:hasPersonalData

Harshvardhan J. Pandit

Indicating data belongs to sensitive or special category

This example shows how data can be indicated as being sensitive or belonging to special category. It also shows the use of PD extension which provides a taxonomy of special categories.

dpv:SensitivePersonalData,dpv:SpecialCategoryPersonalData

Harshvardhan J. Pandit

Indicating data being collected and derived

This example shows a process which first collects email address from the data subject, and then uses it to derive an account identifier. The seeming duplication in information across processing, personal data category, and data source actually represents three distinct concepts - which can be used in various ways for data governance, or legal compliance e.g. to retrieve all data which is collected or to ensure all collected data has a source.

dpv:CollectedPersonalData,dpv:ProvidedPersonalData,dpv:DerivedPersonalData

Harshvardhan J. Pandit

Indicating processing conditions for duration and location

This example shows processing conditions where the use (of data or technology) takes place over 6 months and in Ireland (IE) and Netherlands (NL)

dpv:ProcessingCondition,dpv:ProcessingDuration,dpv:ProcessingLocation

Harshvardhan J. Pandit

Indicating storage conditions for duration, location, deletion, and restoration

This example shows storage conditions for a 'store' processing operation. It has a duration valid until the event 'account closure' occurs. It has a storage location situated in Ireland (IE) and Netherlands (NL). The deletion occurs 6 months after the event 'account closure'. And restoration is implemented by using (stored) data located in backup systems in Ireland (IE).

dpv:StorageCondition,dpv:StorageDuration,dpv:StorageLocation,dpv:StorageDeletion,dpv:StorageRestoration

Harshvardhan J. Pandit

Indicating data volume, geo-location coverage, data subject scale, and a processing scale

This example shows how data volume, data subject scale, and geographic scale can be indicated along with optional information about the exact values involved. It also shows how a qualified scale can be provided as 'processing scale' based on some criteria (not described here).

dpv:ProcessingScale,dpv:GeographicCoverage,dpv:DataVolume,dpv:DataSubjectScale

Harshvardhan J. Pandit

This example shows the various ways in which duration can be expressed - as a period of time (6 months), as an end date, or as a fixed number of occurrences, or until an event occurs. The example also show some 'bad practices' where the information is expressed directly as strings - and instead shows the benefits of providing semantic information to explicitly indicate what kind of a duration it is which is necessary for unambiguous interpretations.

dpv:Duration,dpv:hasDuration

Harshvardhan J. Pandit

This example shows the various ways in which frequency can be expressed, including combining frequency with duration to express complex information such as once per day for 6 months

dpv:Frequency,dpv:hasFrequency

Harshvardhan J. Pandit

Specifying necessity and importance in context

This example shows a process where email address is required to be collected, and name can be optionally collected. Note that the necessity applies to the entire process i.e. both personal data and the collect processing operation. It also provides an indication of the importance of the process - for example to indicate which processes are important for the organisation (primary importance) and which are not as important or are not crucial (secondary importance).

dpv:Necessity,dpv:hasNecessity

Harshvardhan J. Pandit

Specifying applicability of information

This example show how the unavailability, or non-applicability, or unknown applicability of information can be expressed using the Applicability concepts. Note that such situations may represent risks or issues that may require additional attention e.g. where the information is unknown, further steps should be taken to determine the exact applicability.

dpv:Applicability,dpv:hasApplicability

Harshvardhan J. Pandit

Specifying status associated with activities

This example shows two processes as 'activities' with the status as ongoing and proposed. The proposed activity can be useful to get an audit or approval or indicate future plans.

dpv:ActivityStatus,dpv:hasActivityStatus

Harshvardhan J. Pandit

Specifying compliance status and lawfulness

This example shows the compliance status associated with activities in terms of the organisation's policies and for the EU GDPR obligations. It shows how compliance issues and lawfulness can be documented as a status associated with a process. For GDPR, it uses the concepts from EU-GDPR extension regarding lawfulness.

dpv:ComplianceStatus,dpv:hasComplianceStatus,eu-gdpr:GDPRLawfulness

Harshvardhan J. Pandit

Specifying the audit status associated with a DPIA

This example shows how a DPIA can be documented as an audit - including a status that indicates audit is needed, and maintaining logs for how the DPIA was approved.

dpv:DPIA,dpv:AuditStatus,dpv:hasAuditStatus

Harshvardhan J. Pandit

Expressing GDPR Right to Data Portability could not be fulfilled due to Identity Verification failure

The following example describes a GDPR Article 20 Data Portability request not being fulfilled due to identity verification failure. The dpv:RequestRequiresAction concept indicates further action is required - specifically to provide identity documents.

dpv:RightExerciseRecord,dpv:AuditStatus,dpv:hasAuditStatus,dpv:Justification,dpv:hasJustification

Harshvardhan J. Pandit

Expressing a right exercise request is delayed due to high volume of requests

The following example uses the justification HighVolumeOfProcesses to represent a high volume of similar processes or requests causing a delay in fulfilling the rights request. The concept dpv:hasDuration is used to indicate the duration of the delay.

dpv:RightNonFulfilmentNotice,dpv:RequestActionDelayed,dpv:Justification,dpv:hasJustification

Harshvardhan J. Pandit

Exercising the right to rectification with contesting accuracy of information as justification

The following example shows the justification ContestAccuracy representing contesting the accuracy of information or process to justify why the right to rectification as per GDPR Article 16 is being exercised. The information in question is represented using dpv:hasPersonalData, with two processes indicating which data should be deleted and the correction.

dpv:RightExerciseActivity,dpv:Justification,dpv:hasJustification

Harshvardhan J. Pandit

Specifying the location of a process

The following example shows the use of LOC extension to express the location of a process. It also shows how the location fixture and locality concepts are useful to indicate information such as data will be stored locally and shared to a remote cloud server.

dpv:Location,dpv:LocationFixture,dpv:LocationLocality,dpv:hasLocation

Harshvardhan J. Pandit

Associating justifications with right exercise non-fulfilment

The following example represents a notice outlining a failure to complete a GDPR Data Portability request due to identity verification failure. The notice provides steps as providing an official ID for identity verification for the data subject to complete in order to continue the request, and outlines the consequence of not doing this would be a failure to complete the request.

dpv:hasJustification,dpv:Justification,dpv:RightNonFulfilmentNotice,dpv:hasRight

Harshvardhan J. Pandit

Using justifications across categories

The justification concept ComplexityOfProcess represents a reason to delay a process due to the complexity of fulfilling it. To instead use it as a justification for not fulfilling the process, we create a new justification that combines the complexity of process and non-fulfilment categories.

dpv:hasJustification,dpv:Justification

Harshvardhan J. Pandit

Expressing data breach notifications to data subjects are not required using a justification

The justification RightsFreedomsImpactUnlikely represents an unlikely impact on rights and freedoms, which can be used as a justification to not provide data subjects with a notification about a data breach involving their personal data as per GDPR Article 35-3b.

dpv:hasJustification,dpv:Justification,risk:DataBreachReport

Harshvardhan J. Pandit

Indicating use of a technical measure and its implementation

This example specifies a technical measure (access control) being used and specifies that it is implemented by using the database software. It also shows how technologies can have technical measures implemented as part of the system, and also how technologies can indicate they have the capability to provide technical measures for other activities.

dpv:TechnicalMeasure,dpv:hasTechnicalMeasure,dpv:isImplementedUsingTechnology,tech:Capability,tech:hasCapability

Harshvardhan J. Pandit

Specifying legitimate interest of a controller

This example shows how the legitimate interest of a controller. It describes 'bad practices' which lead to ambiguity or lack crucial information, and also describe how legitimate interest can be associated with a purpose within and outside of specific purposes. It also shows alternate ways of defining legal basis and purpose in relation to each other - for cases where such information is needed. Though we *strongly* recommend always using dpv:Process and declaring each concept such as purpose, legal basis, processing, personal data explicitly and separately for consistency and ease of reuse.

dpv:LegitimateInterest,dpv:LegitimateInterestOfController

Harshvardhan J. Pandit

Specifying permissions and prohibitions

This example show a process where service provision based on consent is permitted, and profiling based on legitimate interest is prohibited

dpv:Permission,dpv:Prohibition,dpv:hasPermission,dpv:hasProhibition

Harshvardhan J. Pandit

Indicating applicable rights

This example shows applicable rights being asserted in a privacy notice. The notice is for a GDPR implementing use-cases and uses the EU-GDPR extension to represent rights under GDPR. It also shows how rights not currently provided by DPV can be associated.

dpv:Right,dpv:hasRight

Harshvardhan J. Pandit

Using DPV and RISK extension to represent risks

This example shows the use of risk concepts in DPV and RISK extension to represent a risk of data breach associated with a process along with its potential consequences and impacts on the data subject. The scenario consists of a risk of data breach with high likelihood and severity, and whose potential consequence includes a loss of data which can lead to financial loss for the data controller and misuse of breached information to cause identity fraud for the data subject. The risk has a mitigation measure, which is to secure the data using the encryption. The residual risk if this measure is applied is shown to have a lower risk level.

dpv:Risk,dpv:hasRisk,dpv:Consequence,dpv:hasConsequence,dpv:Impact,dpv:hasImpact,dpv:Likelihood,dpv:hasLikelihood,dpv:Severity,dpv:hasSeverity,dpv:RiskLevel,dpv:hasRiskLevel,dpv:RiskMitigationMeasure,dpv:isMitigatedByMeasure,dpv:hasImpactOn,dpv:ResidualRisk,dpv:hasResidualRisk

Harshvardhan J. Pandit

Using DPV and RISK extension to represent incidents

This example shows the use of incident concepts in DPV and RISK extension to represent a data breach incident along with its potential and actual (i.e. occurred) consequences and impacts on the data subject. It shows the consequences of the incident as loss of data, and which is being misused to cause identity fraud. It also refers to the further risk of financial loss, and associates the incident with a previously identified risk (not elaborated in this example). Note that incident details such as timestamps and durations are not shown in this example.

risk:Incident,risk:IncidentStatus,dpv:hasStatus,dpv:Impact,dpv:hasImpact,risk:refersToRisk,risk:DataBreach

Harshvardhan J. Pandit

Indicating personal data involved in an incident

This example shows how existing DPV concepts and relations are used to describe what personal data a data breach incident affected and how the data was secured before the incident.

risk:Incident,dpv:hasDuration,dpv:Duration,dpv:hasTechnicalMeasure

Harshvardhan J. Pandit

Using risk controls to express how tech/org measures address the risk

In this example, risk controls are used to indicate the technical measure of encryption is used to remove the consequence of misusing the data if it is breached.

dpv:Risk,risk:DataBreach,dpv:hasRiskLevel,dpv:RiskLevel,dpv:hasConsequence,dpv:Consequence,risk:hasControl,risk:RiskControl

Harshvardhan J. Pandit

Using Notice Layer and Icon in a Consent Notice

This example shows a Consent Notice that is structured in 2 layers - first for a summary and a second layer providing detailed overview of the intended processing. The layers contain controls for consent and rights which are accompanied by the label to be used e.g. for the button in the UI, and the icon to be displayed alongside it. This example also shows how a consent notice can be expressed in a machine-readable form in a manner that is similar to and can be used to create a graphical notice such as on a website or in a mobile app.

dpv:ConsentNotice,dpv:NoticeLayer,dpv:NoticeIcon,dpv:hasNoticeLayer,dpv:hasNoticeIcon

Harshvardhan J. Pandit

Tracking the status of a Notice across its lifecycle

In this example, statuses associated with a notice are maintained in a record. The first part shows a notice status within a common process representing all users showing the notice has been communicated i.e. shown or delivered to the users. The second method shows a data processing record where the notice status is included as part of other matters e.g. data collection or rights exercise. The third method shows a record containing only the notice status for a specific user. The fourth method shows how the notice status can also be recorded as part of the notice metadata itself.

dpv:NoticeStatus,dpv:hasNoticeStatus

Harshvardhan J. Pandit

Expressing involvement of a 'human subject' in a process

This example shows how the involvement of humans can be expressed in various contexts. The first part shows how a specific individual can be asserted to be involved as a 'human subject' in some process. The second part shows how a process or service can assert the involvement of specific categories of humans as subjects. The third part shows how humans can be expressed to be involved in a specific role (as participants) and are declared to be vulnerable. The fourth part clarifies the distinction between stating involvement of users as humans for oversight, and as data subjects in relation to their personal data.

dpv:HumanSubject,dpv:hasHumanSubject,dpv:DataSubject,dpv:hasDataSubject,dpv:hasHumanInvolvement,dpv:HumanInvolvement

Harshvardhan J. Pandit

Expressing involvement of tracking and profiling in processing

<p>This example shows how the involvement of tracking and profiling can be expressed within a process. The first method simply states that tracking and profiling occur - this should be considered as bad practice as it does not clarify what the tracking and profiling involves in terms of data and entities - in particular what is being inferred as part of the profiling of data subjects. The second method is a verbose representation showing tracking is a composite process consisting of collecting and using location to generate a 'location tracking data' for the individual, which is then used in the profiling process to infer financial status of the individual.</p>
<p>Through the explicit details of data involved in tracking and profiling, the transparency and accountability principles are easier to satisfy, and we can additionally perform appropriate risk/impact assessments to analyse whether the tracking and profiling should be allowed or not. The verbosity also shows that tracking and profiling are two separate processes - which is essential when the same tracking or profiling occurs in more than one process. The last part shows how this verbosity can be reduced by taking the tracking and profiling (which as mentioned earlier are likely to be common to several processes) and assigning them a unique IRI or identifier, and using to indicate their involvement in a process.</p>

dpv:Tracking,dpv:Profiling

Harshvardhan J. Pandit

Representing contract metadata and controls

The below example shows using [[DCT]] and DPV properties to represent metadata about contracts. [[DCT]] is used for generic properties such as titles and descriptions, as well as contract-specific properties such as when it was accepted by all parties and the provenance of the contract document. The DPV properties are useful to express properties such as entities involved in specific roles such as Service Provider or a Data Controller, and to denote the type of contract which is useful for its interpretation - such as whether it is a negotiated or a standard form (non-negotiated) contract.

Harshvardhan J. Pandit

Representing the status of contracts

This example shows how the lifecycle of a contract in terms of its drafting and acceptance, as well as the fulfilment of its requirements and whether they have been breached.

dpv:Contract,dpv:ContractStatus,dpv:hasContractStatus,dpv:ContractFulfilmentStatus,dpv:hasContractualFulfilmentStatus

Harshvardhan J. Pandit

Representing clauses or terms within a contract

This example shows how specific clauses in a contract can be modelled, and also how their fulfilment status can be represented and tracked.

dpv:ContractualClause,dpv:hasContractualClause,dpv:ContractFulfilmentStatus,dpv:hasContractualFulfilmentStatus

Harshvardhan J. Pandit

Stating status of Legal Obligations

This example shows how the status of using legal obligations can be represented in terms of it being carried out and it being completed. Note that though the legal obligation has been stated as 'completed', this is not an assessment of whether the requirements of the legal obligation have been completed and are verified, but instead the status represents the use of legal obligation as a legal basis within the process is completed.

dpv:LegalObligation,dpv:LegalObligationStatus

Harshvardhan J. Pandit

Stating status of Legitimate Interest

This example shows how the status of using legitimate interests can be represented in terms of whether the existence and use of legitimate interest has been communicated to the data subject, and whether the data subject has objected to its use.

dpv:LegitimateInterest,dpv:LegitimateInterestStatus

Harshvardhan J. Pandit

Stating status of using Official Authority

This example shows how the status of using the official authority as the legal basis can be represented.

dpv:OfficialAuthorityOfController,dpv:OfficialAuthorityExerciseStatus

Harshvardhan J. Pandit

Stating status of using Public Interest

This example shows how the status of using public interest as the legal basis can be represented.

dpv:PublicInterest,dpv:PublicInterestStatus

Harshvardhan J. Pandit

Stating status of using Vital Interest

This example shows how the status of using vital interest as the legal basis can be represented.

dpv:VitalInterest,dpv:VitalInterestStatus

Harshvardhan J. Pandit

Stating status of Rule fulfilment

This example shows how the status of rules can be expressed in terms of their fulfilment or violation.

dpv:RuleFulfilmentStatus

Harshvardhan J. Pandit

Role of dpv:Processing and using it in dpv:Process

<p>This example shows the myriad ways that processing could be used to describe other non-processing operation information such as personal data and entity involved. To accurately represent the information in a consistent and reusable manner, we recommend using dpv:Process as the way to combine concepts in to a 'unit' and to reuse this in other processes. This means dpv:Processing only specifies information about the processing operation involved, and optionally the technology being used if it is relevant to the context.</p>
<p>In Method 1, the processing instance contains personal data and entity involved - this is not recommended as the instance now contains information not related to the processing operation itself. Method 2 shows a processing instance which is implemented using a specific technology. This is acceptable as it describes the processing operation in terms of involved technology, and can be a way to reuse the processing operation in other processes while someone (e.g. IT department) can change the underlying technology. Method 3 represents the best practice of using dpv:Process to describe all concepts in a modular and granular manner with a separation of concerns. Processes can include other processes - so we can describe processing and technology and data involved as a process and involve it in other processes. This makes the task of finding information easier as we only have to look for composition of processes, instead of investigating each purpose or processing or another concept involved for what data or technology it involves.</p>

dpv:Processing,dpv:hasProcessing,dpv:isImplementedUsingTechnology,dpv:isImplementedByEntity

Harshvardhan J. Pandit

Using Risk Controls to indicate measures adopted for a specific event

<p>This example shows how risk controls can be used to represent the specific measures in place to detect, monitor, address, and inform stakeholders regarding risks, consequences, and impacts. The first part shows a risk with its associated consequence and resulting impact. The second part shows the process where this risk is present, and the specific controls put in place to: (1) monitor the process for vulnerabilities and avoid the source of risk with oversight,; (2) avoid the consequence event; and (3) monitor for occurrence of the impact event, and if it occurs to halt it and to inform the affected person.</p>
<p>In this example the specific details of the control such as the technology being used, or what characteristics are changed when avoiding an event are not specified to reduce the length of content. To express this information, the specific control can reference two events as Risk and Residual Risk respectively - one which shows the initial values such as likelihood, and another one which shows the modified values. Currently the DPVCG does not dictate a specific method for expressing such information, and welcomes suggestions on best practices for the same.</p>

risk:RiskControl,risk:controls

Harshvardhan J. Pandit

Flexibility of RISK taxonomy in expressing varying roles

<p>This example shows how the same concept <code>risk:DataBreach</code> can take on different roles across contexts. The first part shows data breach as a consequence of a malware attack, while the second part shows it as a risk source which could lead to identity fraud and misuse. In these, the same concept of data breach being a consequence or a risk source is context-dependant. The RISK extension does not specify or assert that a data breach is always a risk source or risk or consequence - only that it has the potential to be these things. Therefore, inclusion of RISK extension in the graph does not 'pollute' it or cause misinterpretations such as data breach showing up as a consequence even though it has been asserted to (only) be a risk source.</p>
<p>The third part shows how these different roles are associated with the concept, and how this can be used in UI/UX to provide users with a list of options for selecting risks. It also shows the distinction between marking or annotating a concept to include it in risk identification process (<code>risk:PotentialRisk</code>) and asserting that the concept is applicable as a risk in a process (<code>dpv:hasRisk</code>). This allows use-cases to directly use the RISK extension's subjective classification of concepts in UI/UX - such as to populate the dropdown of risks, and also provides flexibility to ignore that and create their own thesauri or categorisations by using the <code>risk:PotentialRisk</code> concept to annotate concepts, or to create specific subclasses for contextual classifications.</p>

risk:PotentialRiskSource,risk:PotentialRisk,risk:PotentialConsequence,risk:PotentialImpact

Harshvardhan J. Pandit

Expressing impact on specific rights

To express a specific right has been impacted, the relevant rights impact concept is utilised along with a rights impact category from the RISK extension, which together indicate a right is being impacted in the specified manner. In this example, a customer of a company has complained that their GDPR rights have been violated. Upon investigation, it was found that the GDPR's Transparency Right (Article 13) was impacted by limiting the scope of the right as not all processing was represented, and further the right was obstructed as it was not easy to obtain the information on the website.

risk:RightsImpact,eu-gdpr:RightsImpact,risk:RightsViolated,dpv:hasImpact

Harshvardhan J. Pandit