Re: Contract type and clauses for Data Processing Agreement

Hi Georg.

See my comments below for the concepts.

Did you use GenAI to generate this? If so, please note the high number 
of hallucinations or concepts that are not present in DPV. Not only does 
this require manually checking concepts are present in DPV, but it also 
makes it difficult to understand how the proposed new concepts are 
supposed to fit with the existing concepts. This takes up a lot of 
time/energy and is not sustainable. It would be helpful if you can 
verify the concepts or find some ways of removing or reducing such 
instances so we can focus more on the actual concepts/modelling needed.

2) dpv:Party is not present in DPV, we have dpv:LegalEntity instead
3) Contract signed and binding, the relevant concept should be the 
status dpv:ContractAccepted
5) dpv:TemporalCoverage does not exist in DPV, we have dpv:Duration; To 
express when a DPA enters in to force and how long it is valid for, 
http://purl.org/dc/terms/valid would be more appropriate
6) dpv:ElectronicAgreement is not the appropriate concept here as the 
phrasing implies this is a measure or control to ensure there are 
copies. Therefore, dpv:MaintainDocuments or dpv:BackupDocuments might be 
a suitable organisational measure
7) ContractGlossary can be a contractual clause type for terms used in 
contract - otherwise dpv:MaintainGlossary as an organisational measure 
means a glossary can be useful in other places as well
8) dpv:DataDeletion, dpv:DataReturn - neither of these exist in DPV. 
Instead, we have DataDeletionPolicy and DataErasurePolicy
9) dpv:DeletionPower - unclear what this means or represents. This is 
should not be modelled as a right in DPV as we limit rights to the 
broader legal concept of right and not contractual rights. This can be a 
contractual clause type if needed - but then we will have too many 
arbitrary types of clauses in DPV. Might make sense to put them in a 
separate extesion.
10) dpv:DataDeletion - see comment #8
11) dpv:DataDeletion - see comment #8
12) dpv:DataDeletion - see comment #8
13) dpv:DefaultDeletionAction - what is this supposed to represent? The 
description "Handling of data when no deletion instruction is provided" 
is not clear for me.
14) dpv:Confidentiality does not exist, we have dpv:ConfidentialityAgreement
15) dpv:Confidentiality - see comment #14
16) dpv:Confidentiality - see comment #14
17) dpv:Confidentiality - see comment #14
18) dpv:Transparency does not exist - we have 
dpv:LegalComplianceAssessment ; though dpv:ComplianceDemonstration can 
be an organisational measure
19) dpv:Audit does not exist ; though dpv:AuditProcedure can be an 
organisational measure
20) dpv:ProcessingRecord does not exist; we have dpv:DataProcessingRecord

NOTE: at this point, I stopped looking at this in detail and only focus 
on items under new concepts column as there are far too many hallucinations.

22) dpv:BreachNotificationAssistance - I don't think "assistance" should 
be a DPV concept. But we can have DataBreachHandlingPolicy as an 
organisational measure which should broadly cover this
25) dpv:SubProcessorManagement - Why is this specifically only for 
sub-processors when it may also be required for processors and maybe 
also for joint controllers? What would a broad concept be for covering 
all of these?
26) dpv:SubProcessorAuthorization - authorisation (note use of EN-GB) 
for what? If this is an approval process to enable processors - then it 
should be a part of the broader concept in #25 - maybe as a policy or 
procedure concept?
27) dpv:GeneralSubProcessorAuthorization - same as #26
28) dpv:SubProcessorChangeNotification - this should be part of a 
broader set of concepts about changes in processors (where 
sub-processors are also processors)
29) dpv:SubProcessorObjectionRight - this is not a "right", and Art.28 
also does not use the word "right" but instead states "giving the 
controller the opportunity to object to such changes". This can be 
extended for a joint controller to object use of processor by another 
controller - so ObjectToUseOfProcessor or something similar would be 
better to cover both scenarios. This might also be more specific to the 
GDPR AFAIK.
31) dpv:LiabilityAllocation - allocation is a weird choice of word here, 
maybe we state this as a policy?
32) dpv:InterPartyCommuncation - IPC is a technical established concept, 
we should not call this the same as that. EstablishCommunicationChannels 
or something similar might be better.
33) dpv:DesignatedNotificationAddress - does this need to be a specific 
concept? Seems like it is part of the above generic 'communication'? 
Also whose email is this and for what purpose?
34) dpv:OfficialLanguage - there is dct:language already?
35) dpv:EntireAgreement - what does "entire agreement" as a concept mean 
here? Seems arbitrary wording?
36) dpv:ProcessorComplianceAssessment - add to organisational measures 
under dpv:ComplianceAssessment ?
37) dpv:InfringementNotification - infringment here is too broad and can 
also cover contractual infringements between parties, which is not what 
we want to model. Maybe dpv:NotifyNonCompliance could be a more 
practical concept?
38) dpv:ApplicableLawAndJurisdiction - we already have 
dpv:hasApplicableLaw so this concept is weirdly worded. Also 
dpv:DisputeResolution does not exist. Maybe what could be helpful here 
is a DisputeResolutionClause concept for contractual clause type.

For the contract types at the end, I have created the following 
generalised concepts. Please review them.

1) ContractPartiesIdentification - clause for identifying parties in the 
contract and their roles
2) ContractExecutionClause - clause stating the onset, duration, and 
other details necessary to execute the contract
3) DataDeletionClause - clause stating data deletion capability given to 
party or parties, and any obligations to carry it out at specific events 
or end of contract
4) RightsFacilitationClause - clause outlining any rights that a party 
or parties will facilitate or assist with

For the other items mentioned, I think they go too deep/specific in to 
the wording in a contract, and we shouldn't aim to mimic/simulate each 
sentence written in a contract, but only the high-level details 
necessary to organise or use a contract.

Regards,
Harsh


On 30/09/2024 19:26, Georg Philip Krog wrote:
> Hi
> 
> I attach an excel sheet for Contract type and clauses for Data 
> Processing Agreement.
> It contains required information fields up for discussion for dpv to 
> provide standard concepts.
> 
> -- 
> Georg Philip Krog
> 
> signatu <https://signatu.com>

-- 
---
Harshvardhan J. Pandit, Ph.D
Assistant Professor
ADAPT Centre, Dublin City University
https://harshp.com/

Received on Monday, 30 September 2024 21:30:33 UTC