dpv:Transfer - suggested additional terms

All:

I have been doing some work on compliance of International Transfers in the context of the DPV, and in modelling such transfers have identified some terms that I feel could be usefully added (if not already provided by another term within the DPV). I would like to contribute the attached list of (11) terms for discussion and consideration. (Apologies if some terms already exist and I have missed this fact).

Harsh has kindly provided some initial feedback and opinions.

Regards
DAVID HICKEY

MA Programme in Data Protection and Privacy Law
Dublin City University.


From: Harshvardhan J. Pandit <me@harshp.com>
Date: Tuesday, 10 August 2021 at 12:52
To: David Hickey <david.hickey26@mail.dcu.ie>, Paul Ryan <paul.ryan76@mail.dcu.ie>
Subject: Re: dpv:Transfer - additional terms
Hello. Yes these are in scope for discussions in DPV.
I would recommend sending these on to the mailing list (no attachments
if possible) so that others can view & comment. Mine are below.

IMHO:

1. Transfer start/end date can be represented using dpv:hasDuration and
something else e.g. strings, or even the Time Ontology
https://www.w3.org/TR/owl-time/
We should not try to model the minor specifics such as dates & times
because these vary too much for consistency across use-cases and designs.

2. Data Exporter & Importer: yes, these are now the terms used by EDPB,
so we should model them. However, they need good working definitions to
be applicable globally (not just GDPR) for them to be included in DPV.
From: COMMISSION DECISION 2010/87/EU Document 32010D0087
‘data exporter’ means the controller who transfers the personal data;
‘data importer’ means the processor established in a third country who
agrees to receive from the data exporter personal data intended for
processing on the data exporter’s behalf after the transfer in
accordance with his instructions and the terms of this Decision and who
is not subject to a third country’s system ensuring adequate protection
within the meaning of Article 25(1) of Directive 95/46/EC;

So it seems that these are GDPR specific, and I would suggest modelling
them in DPV-GDPR as they are defined.

3. TransferCountry: There are many locations associated with transfers
that need to modelled for relevance: Sender, transmissions (where does
the data flow through), Recipient. Here the sender and recipient can be
the same entity or different ones. And the transfer may end up in a
server, so the location of the server is what we want rather than
recipient. What is of relevance here is Jurisdiction rather than Country
(EU is not a country, Country is one type of Jurisdiction). So this
needs discussions to model in DPV.

4. TransferLegalBasis: It is unclear to me what is being proposed here.
The A.45/46/49 bases are in dpv-gdpr. We've agreed to (if I remember
correctly) group them within dpv-gdpr as per legal bases in dpv i.e.
those for consent, those for A6, for transfer etc.

5. Safeguard: A safeguard is a tech/org measure in principle. As a
concept, it has been proposed for inclusion.
As per ThomsonReuters, safeguard is: "Measures taken by a data owner,
controller, or processor to protection personal data or information." -
which is the same definition as tech/org measure. So the property
hasTechOrg... can be used along with Safeguard as a concept to define
where TechOrg...Measure is used as a safeguard. If there is a need for a
specialised hasSafeguard property, then this needs to be proposed.

Then the question is whether an use-case needs explicit notion of using
a TechOrg..Measure as a Safeguard and where the term Safeguard is
distinct from TechOrg...Measure. If the answer is yes, then the concept
is valid and should be included.

6. Supplementary Measure: Same boat as Safeguards - they're
TechOrg..Measures used in a specific context.
From: Recommendations 01/2020 on measures that   supplement transfer
tools ... by EDPB
The  situation  in  the  third  country  to  which  you  are
transferring data may still require that you supplement these transfer
tools and the safeguards they  contain  with  additional  measures
(“supplementary measures”) to ensure an essentially equivalent  level of
protection.

So seems to be a GDPR concept, and a subclass of TechOrg...Measure. I
would suggest including these in dpv-gdpr because they're heavily
reliant on interpretation in the EU; OR use another term since
supplementary measure is not sufficient to describe what it actually
means (equate protection across jurisdictions).

Regards,
Harsh

On 10/08/2021 11:30, David Hickey wrote:
>  From the work I have been doing on compliance of International
> Transfers in the context of the DPV, and our recent discussions on
> possible extensions to the vocabulary, I would appreciate your guidance
> on whether the following is appropriate for discussion with the DPVCG or
> subgroup. These are terms that I feel would be usefully added if not
> provided by another term within the DPV.
>

--
---
Harshvardhan J. Pandit, Ph.D
Research Fellow
ADAPT Centre, Trinity College Dublin
https://harshp.com/

-- 
__

Séanadh Ríomhphoist/_

Email Disclaimer__
**

Tá an ríomhphost seo agus 
aon chomhad a sheoltar leis faoi rún agus is lena úsáid ag an seolaí agus 
sin amháin é. Is féidir tuilleadh a léamh anseo. 
<https://www.dcu.ie/iss/seanadh-riomhphoist.shtml>  
<https://www4.dcu.ie/iss/seanadh-riomhphoist.shtml>*
_

This e-mail and any 
files transmitted with it are confidential and are intended solely for use 
by the addressee. Read more here. 
<https://www.dcu.ie/iss/email-disclaimer.shtml> _
*_