ISO/IEC TS 27560:2023 Implementation Guide

The ISO/IEC TS 27560:2023 Privacy technologies — Consent record information structure provides guidance on the creation of information records for representing information about consent. It also provides guidance on the use of this information in the form of 'receipts' that can be provided to assert the information in records. This document is a guide for the implementation of ISO/IEC TS 27560:2023 by using the Data Privacy Vocabulary (DPV) to represent information. Additionally, this document also provides guidance on using ISO/IEC TS 27560:2023 for meeting GDPR requirements regarding consent records.

prefix	URI
dpv	https://w3id.org/dpv#
dpv-gdpr	https://w3id.org/dpv/dpv-gdpr#
dct	http://purl.org/dc/terms/
ex	https://example.com/

27560 term	req.?	relevant GDPR clause	req.?	DPV concept
definitions
consent	-	4-11 consent	-	dpv:ExpressedConsent
consent record	-	7-1 demonstrate consent	-	dpv:ConsentRecord
consent receipt	-	13 info on legal basis	-	dpv:ConsentReceipt
consent type	-	4-11; 9-2a	-	dpv:Consent subtypes
PII Principal	-	4-1 data subject	-	dpv:DataSubject
PII Controller	-	4-7 controller; 26-1 joint controllers	-	dpv:DataController, dpv:JointDataControllers
PII Processor	-	4-8 processor; 28-2 processor appointed by processor	-	dpv:DataProcessor, dpv:DataSubProcessor
Third Party	-	4-10 third party	-	dpv:ThirdParty
Processing of PII	-	4-2 processing	-	dpv:Processing
Sensitive PII	-	9 special categories of data	-	dpv:SensitivePersonalData, dpv:SpecialCategoryPersonalData
PII	-	4-1 personal data	-	dpv:PersonalData
metadata
schema version	Y	N/A	-	dct:conformsTo
record id	Y	N/A	-	dct:identifier, dpv:hasIdentifier
receipt id	Y	N/A	-	dct:identifier, dpv:hasIdentifier
pii principal id	Y	N/A	-	dpv:DataSubject, or dpv:hasDataSubject with dct:identifier
processing fields
privacy notice	Y	13, 14 information to be provided	Y	dpv:PrivacyNotice, dpv:ConsentNotice
language	Y	N/A	-	dct:language
purpose	Y	6-1a purpose	Y	dpv:Purpose
purpose type	N	N/A	-	dpv:Purpose parent in taxonomy
lawful basis	N	6 legal basis	Y	dpv:LegalBasis
pii information	Y	N/A	-	dpv:hasPersonalData (reference to information)
pii controllers	Y	N/A	-	dpv:hasDataController (reference to information)
collection method	N	13-1 collected from data subject; 14-2f source	Y	dpv:DataSource, dpv:Collect
processing method	N	4-2 processing; 30-2b processing categories; 13-2f, 14-2g, 151-h automated decision making, logic, consequences; 35-1b large scale processing of special categories; 35-1c large scale of processing	Y	dpv:Processing and parent in taxonomy, dpv:AutomationOfProcessing, dpv:Profiling, dpv:AlgorithmicLogic, dpv:Consequence; dpv:DataVolume, dpv:ScaleOfProcessing
storage locations	Y	15-2 third country	Y	dpv:StorageLocation. dpv:Jurisdiction
retention period	Y	13-2a, 14-2a, 15-1d storage period or criteria; 30-1f erasure time limit	Y	dpv:StorageCondition, dpv:StorageDuration, dpv:StorageDeletion
processing location	N	13-1f, 14-1f, 15-2 transfer to third country	Y	dpv:Location, dpv:Jurisdiction
geographic restrictions	N	13-1f, 14-1f, 15-2, 30-1e, 30-2c, 44, 45, 46, 47, 48, 49-1a transfer to third country	Y	dpv:Location, dpv:Jurisdiction, dpv:Rule
service	N	N/A	-	dpv:Service (proposed)
jurisdiction	Y	N/A	-	dpv:Jurisdiction
recipient third parties	Y	4-9 recipient; 4-10 third party	Y	dpv:Recipient, dpv:ThirdParty
withdrawal method	Y	7-3, 13-2c, 14-2d withdrawing consent	Y	dpv:ConsetWithdrawalProcess (proposed Organisational measure)
privacy rights	N	13-22 rights	Y	dpv:DataSubjectRight, dpv:RightExerciseNotice
codes of conduct	N	24-3, 32-3, 35-8, 40 codes of conduct; 42 certification	N	dpv:CodeOfConduct, dpv:CertificationSeal
impact assessment	N	35 DPIA	N	dpv:ImpactAssessment
authority party	N	13-2d, 14-2e, 15-1f complaint to authority; 51 supervisory authority; 56 lead authority.	Y	dpv:Authority
personal data fields
pii type	Y	4-1, 14-1d, 15-1b personal data categories	Y	dpv:PersonalData
pii attribute id	N	N/A	-	dct:identifier
pii optional	N	13-2e, 35 necessity of personal data	Y	dpv:Necessity
sensitive pii category	N	N/A	-	dpv:SensitivePersonalData
special pii category	N	9 special categories of data	Y	dpv:SpecialCategoryPersonalData
party fields
party id	Y	N/A	-	dct:identifier, dpv:hasIdentifier
party address	Y	13-1a, 14-1a identity of controller	Y	dpv:hasAddress
party email	N	N/A	-	dpv:hasContact
party url	N	N/A	-	dpv:hasContact
party phone	N	N/A	-	dpv:hasContact
party name	Y	13-1a, 14-1a identity of controller	Y	dpv:hasName
party role	N	4-1 data subject; 4-7 controller; 4-8 processor; 4-9 recipient; 4-10 third party; 4-17 representative; 4-21 supervisory authority	Y	dpv:DataSubject, dpv:DataController, dpv:DataProcessor, dpv:Recipient, dpv:ThirdParty, dpv:Representative; dpv:Authority
party contact	Y	13-1a, 14-1a contact details of controller	Y	dpv:hasContact
party type	Y	4-9 recipient, data importer and data exporter (external concepts)	Y	dpv:Recipient, dpv:DataImporter, dpv:DataExporter, dpv:DataSource
event fields
event time	Y	7-1 demonstrate consent	Y	dct:date
validity duration	Y	N/A (external guidance requires validity)	Y	dct:valid
entity id	Y	N/A (assumed roles, e.g. data subject, controller)	Y	dpv:isImplementedByEntity
event type	Y	4-11 (regular or expressed) consent; 9-2a explicit consent	Y	dpv:Consent subtype
event state	Y	4-11, 9-2a consent given; 7-3 withdrawal of consent; 13, 14 notice for consent; (from derivations) lapsed validity, invalidation authorities, termination by controller		dpv:ConsentStatus

DPV-27560 Consent Record

The IRI `https://w3id.org/dpv/schema/iso-27560` defines the [[DPV-27560]] as a schema or profile for [[ISO-27560]].

Due to way DPV is utilised and expressed (e.g. RDF graph, JSON) - there is no necessity to replicate the four sections of [[ISO-27560]] as information is linked and expressed as a single graph. Therefore, the DPV implementation ignores the structuring into sections.

Record Metadata

Information representing the metadata in the header field containing information about the record.

Field	Cardinality	DPV Concept	DPV Property
Schema Version	1	N/A	dct:conformsTo
Record Identifier	1..*	N/A	dpv:hasIdentifier
Data Subject	1	dpv:DataSubject	dpv:hasDataSubject

Schema Version

This field MUST be present.

The specific version of the schema (`schema_version` in [[ISO-27560]]) used to interpret the record and its information, indicated using dct:conformsTo with the corresponding IRI from [[[#namespaces]]]. Future changes to the schema will result in suffixes to this IRI e.g. `iso-27560-v2`. To indicate conformance with specific requirements such as from GDPR, a separate schema or profile IRI must be utilised, as seen in [[[#namespaces]]].

Using the 'default' schema version representing conformance with [[ISO-27560]]:

{
    "@id": "https://example.com/UNIQUE-ID",
    "@type": "dpv:ConsentRecord",
    "dct:conformsTo": "https://w3id.org/dpv/schema/iso-27560"
}

Using the 'GDPR' schema version representing conformance with [[GDPR]] requirements e.g. information to be maintained as per Article 13 and Article 14:

{
    "@id": "https://example.com/UNIQUE-ID",
    "@type": "dpv:ConsentRecord",
    "dct:conformsTo": "https://w3id.org/dpv/schema/iso-27560-GDPR"
}

Record Identifier

This field MUST be present.

The unique identifier (`record_id` in [[ISO-27560]]) associated with this record, indicated using dct:identifier. This can be a [[ISO-27560]] recommended UUID-4 string or an IRI.

Even if the IRI or `@id` field represents a unique identifier, this information must be specified using `dct:identifier` as the IRI may refer to a copy or alternate location of the same record.

Using UUID-4 without IRI:

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dct:identifier": "a6f58318-72e6-46a2-bfd7-f36d795e30cd"
}

Using UUID-4 with IRI:

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dct:identifier": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd"
}

Data Subject

This field MUST be present.

The data subject (`pii_principal_id` in [[ISO-27560]]) associated with the consent (record), indicated using dpv:hasDataSubject. The data subject can be represented by an instance of dpv:DataSubject or an identifier.

Using an IRI referring to an instance of `dpv:DataSubject` (this is best practice):

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasDataSubject": "https://example.com/data-subject-id"
}

Using an ad-hoc instance of `dpv:DataSubject` that also specifies the email used to identify the data subject (this is best practice for portable self-contained records). Alternatively, the email may also be directly used as the identifier - though this is not recommended as it does not suit data protection by design:

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasDataSubject": {
        "@id": "https://example.com/data-subject-id",
        "@type": "dpv:DataSubject",
        "dct:identifier": "[email protected]"
    }
}

Using an identifier that can be interpreted implicitly as an instance of `dpv:DataSubject`:

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasDataSubject": "a6f58318-72e6-46a2-bfd7-f36d795e30cd"
}

Additional Metadata

Information such as who maintains or published the record, when was it created or modified, and its provenance is not covered by [[ISO-27560]] as it is considered "implementation detail". To assist in maintaining this information, the following fields from [[DC-TERMS]] are suggested for documenting this information in an optional and non-normative manner:

dct:accessRights: information on who can access the consent record.
dct:contributor: entity or entities that have contributed to the information within the consent record.
dct:created: date/time for when the consent record was created.
dct:creator: entity that created the consent record. NOTE: this entity may be different from the publisher of the consent record, e.g. a processor (creator) manages the record for a controller (publisher).
dct:hasPart (with inverse dct:isPartOf): to associate with a part of the consent record, e.g. where the information in a consent record may be maintained separately or partitioned based on common information for efficiency.
dct:hasVersion (with inverse dct:isVersionOf): to associate one consent record with its updated version, e.g. where each event in a consent record results in a new consent record.
dct:replaces (with inverser dct:isReplacedBy): to associate the consent record which is being replaced, e.g. where the other consent record is no longer in use and this is a new consent record intended to replace it.
dct:issued: date/time associated with 'formal issuance' of the consent record, e.g. where dct:created is a timestamp for when the record was generated by a machine agent and where dct:issued captures its formal acceptance as a legally relevant record.
dct:modified: date/time for when the consent record was modified.
dct:provenance: information about the provenance of the consent record, e.g. where the record has been transferred between entities.
dct:publisher: entity or entities that 'publish' the consent record i.e. make it available within some contextual sense, e.g. to produce it within an audit or legal investigation.
dct:source: information on the sources used within the consent record, e.g. other records or logs that should be associated to record the provenace of information.
dct:valid: date/time until when this record can be considered valid. NOTE: this refers to assessing validity of the record as a whole and does NOT refer to validity of consent events or the processing specified within the record.

Notice Fields

These fields refer to information about the notice that has been shown to request consent. In [[ISO-27560]], these fields are part of the Processing section.

Field	Cardinality	DPV Concept	DPV Property
Notice	1..*	dpv:Notice	dpv:hasNotice
Notice Language	1..*	N/A	dct:language

Notice

This field MUST be present.

Reference to the specific version of the notice (`privacy_notice` in [[ISO-27560]]) associated with consent, indicated using `dpv:hasNotice` and a reference to the notice or an instance of `dpv:ConsentNotice`. If there are multiple notices - then each must be indicated separately. Multiple notices can be associated where such notices are part of the same context e.g. shown one after the other, or where they are associated over time, e.g. one notice shown initially when requesting and another when re-confirming it at a later time.

In DPV, the concepts `dpv:PrivacyNotice` and `dpv:ConsentNotice` have different intended meanings - a consent notice is a specific privacy notice associated with consent, most commonly providing information in order to request consent. Whereas, a privacy notice can also refer to other documents providing information, such as what is commonly called as 'privacy policy'. For the purposes of the consent record, both documents can be included, but `dpv:ConsentNotice` MUST be used when referring to the notice used for providing information for consent.

Using a UUID-4 reference to the notice:

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasNotice": "a6f58318-72e6-46a2-bfd7-f36d795e30cd"
}

Using an ad-hoc instance of `dpv:ConsentNotice`. This has the benfit of representing other information such as the language used, date of validity for the notice, as well as the interactions performed by the data subject (out of scope for this document). A benefit of providing such information is its use in determining validity of consent e.g. where a notice's temporal coverage has expired and a new notice must be shown to confirm the existing consent (see next example):

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasNotice": {
        "@id": "https://example.com/notices/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
        "@type": "dpv:ConsentNotice",
        "dct:date": "2023-01-01",
        "dct:language": "EN",
        "dct:coverage": "2023-01-01/P12M"
    }
}

Multiple instances of notices with different timestamps:

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasNotice": {
        "@id": "https://example.com/notices/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
        "@type": "dpv:ConsentNotice",
        "dct:date": "2022-01-01",
        "dct:language": "EN",
        "dct:coverage": "2022-01-01/P12M"
    }, 
    "dpv:hasNotice": {
        "@id": "https://example.com/notices/a6f58318-72e6-46a2-bfd7-f36d795e30cd-2",
        "@type": "dpv:ConsentNotice",
        "dct:date": "2023-01-01",
        "dct:language": "EN",
        "dct:coverage": "2023-01-01/P12M"
    }
}

Notices declared in the context of consent events (or statuses in DPV). The first status of `dpv:ConsentGiven` states the notice shown when first consent was given. The last status of `dpv:RenewedConsentGiven` states another notice shown when renewing or re-confirming the earlier given consent:

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasStatus": {
        "@type": "dpv:ConsentGiven"
        "dct:date": "2022-01-01",
        "dpv:hasNotice": {
            "@id": "https://example.com/notices/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
            "@type": "dpv:ConsentNotice",
            "dct:language": "EN"
        }
    }, 
    "dpv:hasStatus": {
        "@type": "dpv:RenewedConsentGiven"
        "dct:date": "2023-01-01",
        "dpv:hasNotice": {
            "@id": "https://example.com/notices/a6f58318-72e6-46a2-bfd7-f36d795e30cd-2",
            "@type": "dpv:ConsentNotice",
            "dct:language": "EN"
        }
    }
}

Notice Language

This field MUST be present.

The language used in the communications regarding consent, such as the information provided within a notice. The language is indicated using `dct:language`, and it is recommende to use standardised notations for representing langauges such as the ISO 639.

For examples, please refer to [[[#notice]]] section.

Processing Fields

[[ISO-27560]] contains 22 fields related to processing activities, and 5 additional fields regarding personal data involved in processing. The structuring of these fields within [[ISO-27560]] is of the form where the "PII Processing" section contains an array of "purposes" where each "purpose" is expressed with its own fields regarding legal basis, collection method, storage locations, and so on. Within the DPV implementation, this is replaced with dpv:PersonalDataHandling so that each instance represents a distinct processing activity with its fields e.g. purposes, personal data, recipients.

Field	Cardinality	DPV Concept	DPV Property
Personal Data Handling	1..*	dpv:PersonalDataHandling	dpv:hasPersonalDataHandling
Purpose	1..*	dpv:Purpose	dpv:hasPurpose
Personal Data	1..*	dpv:PersonalData	dpv:hasPersonalData
Personal Data Type	1..*	Personal Data taxonomy	rdf:type
Personal Data Identifier	0..*	N/A	dct:identifier
Personal Data Necessity	0..*	dpv:Necessity	dpv:hasNecessity
Sensitive/Special Category	0..*	dpv:SensitivePersonalData, dpv:SpecialCategoryPersonalData	rdf:type
Processing Operations	0..*	dpv:Processing	dpv:hasProcessing
Data Source	0..*	dpv:DataSource	dpv:hasDataSource
Storage Condition	1..*	dpv:StorageCondition, dpv:StorageLocation, dpv:StorageDuration, dpv:StorageDeletion	dpv:hasStorageCondition
Processing Condition	0..*	dpv:ProcessingCondition, dpv:ProcessingLocation, dpv:ProcessingDuration	dpv:hasProcessingCondition
Geographic Restriction	0..*	dpv:Rule	dpv:hasRule
Data Controller	1..*	dpv:DataController	dpv:hasDataController
Legal Basis	0..*	dpv:LegalBasis	dpv:hasLegalBasis
Recipients	1..*	dpv:Recipient	dpv:hasRecipient
Consent Change & Withdrawal	1..*	dpv:ConsentManagement, dpv:ProvideConsent, dpv:ChangeConsent, dpv:WithdrawConsent	dpv:hasConsentManagement
Jurisdiction	1..*	dpv:Jurisdiction	dpv:hasJurisdiction
Rights	1..*	dpv:Right	dpv:hasRight
Services	0..*	dpv:Service	dpv:hasService
Code of Conduct	0..*	dpv:CodeOfConduct	dpv:hasOrganisationalMeasure
Impact Assessment	0..*	dpv:ImpactAssessment	dpv:hasAssessment

Personal Data Handling

This field MUST be present.

`dpv:PersonalDataHandling` is a concept that represents a process or 'unit' for combining relevant details such as purposes, processing, personal data categories, recipients, and so on. Instances of `dpv:PersonalDataHandling` can be used to differentiate between information regarding processing - such as where different purposes are used or that lead to different recipients. Such instances can also be nested within other instances to create a 'modular' structuring of processing activities.

Following the [[ISO-27560]] model requires creating a concept called 'purposes' and to utilise an array or a list to hold the associated 'purpose' instances. Given that DPV prefers a strict taxonomy expressed in a graph representation, following the same model would lead to non-intuitive structures. Further, other similar lists such as those for 'pii_type' also require creation of new concepts to represent groups or collections of the actual intended concepts.

The term 'Personal Data Handling' is non-intuitive and difficult to grasp. By contrast, the term 'Process' is commonly used and is intuitive. Therefore, a new concept called `Process` should be added, and for backwards compatibility be declared as a subtype of `PersonalDataHandling`. The existing relations benefit from this by use of phrasing such as "personal data associated with a process".

A single instance of Personal Data Handling:

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": {
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasPurpose": "dpv:Marketing",
        "dpv:hasPersonalData": "dpv-pd:EmailAddress"
    }
}

Using multiple instances of Personal Data Handling to separate purposes and associated personal data:

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": {
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasPurpose": "dpv:PaymentManagement",
        "dpv:hasPersonalData": "dpv-pd:EmailAddress"
    },
    "dpv:hasPersonalDataHandling": {
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasPurpose": "dpv:IdentityVerification",
        "dpv:hasPersonalData": "dpv-pd:OfficialID"
    }
}

Using nested instances of Personal Data Handling to separate purposes and associated personal data within the larger instance. In this case, the processing activity is for the same purpose, but the personal data are being sent to different recipients. Alternatively, the same information could have been repeated within each instance to avoid nesting:

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": {
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasPurpose": "dpv:PaymentManagement",
        "dpv:hasPersonalDataHandling": {
            "@type": "dpv:PersonalDataHandling",
            "dpv:hasPersonalData": "dpv-pd:EmailAddress",
            "dpv:hasRecipient": "ex:CompanyA"
        },
        "dpv:hasPersonalDataHandling": {
            "@type": "dpv:PersonalDataHandling",
            "dpv:hasPurpose": "dpv:IdentityVerification",
            "dpv:hasPersonalData": "dpv-pd:OfficialID",
            "dpv:hasRecipient": "ex:CompanyB"
        }
    }
}

Purpose

This field MUST be present.

The purpose of processing personal data, expressed in DPV using hasPurpose as an instance of Purpose.

[[ISO-27560]] has an additional field called 'purpose_type' that describes the category of the purpose. In DPV, this is declared by using concepts from the purpose along with `rdf:type`. For additional information, such as descriptions, relevant DCT relations should be used.

Where multiple purposes are present within the same or single context, for example the consent record or a personal data handling instance, the interpretation is that they are all applicable for that context. For example, if a personal data handling instance contains 3 purposes - then it is presumed that the consent is for carrying out each of the 3 purposes.

To declare that ALL purposes must occur together i.e. they cannot be carried out independently, the appropriate semantic relations should be used to express this information - for e.g. by declaring the 3 required purposes as the 'type' for a new combined purpose.

Caution is advised when modelling consent as jurisdictional requirements such as those from GDPR e.g. Recital 32 states "Consent should cover all processing activities carried out for the same purpose or purposes. When the processing has multiple purposes, consent should be given for all of them.". This means all purposes listed within a record pertaining to a single consent are to be used with that single consent as the legal basis.

Specifying the purpose with type based on the DPV Purpose taxonomy and a description

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": {
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasPurpose": {
            "@type": "dpv:Marketing",
            "dct:description": "Sending newsletters to the customer"
        },
        "dpv:hasPersonalData": "dpv-pd:EmailAddress"
    }
}

Specifying multiple purposes with separate types to indicate they both are applicable independently

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": {
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasPurpose": {
            "@type": "dpv:Marketing",
            "dct:description": "Sending newsletters to the customer"
        },
        "dpv:hasPurpose": {
            "@type": "dpv:CommunicationManagement"
        },
        "dpv:hasPersonalData": "dpv-pd:EmailAddress"
    }
}

Specifying a combined purpose with multiple types to indicate the purpose is required for all indicated categories:

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": {
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasPurpose": {
            "@type": [ "dpv:Marketing", "dpv:CommunicationManagement" ],
            "dct:description": "Sending newsletters to the customer"
        },
        "dpv:hasPersonalData": "dpv-pd:EmailAddress"
    }
}

Personal Data

This field MUST be present.

The personal data ('pii information' in [[ISO-27560]]) involved in processing activities, associated using dpv:hasPersonalData and instances of dpv:PersonalData.

In [[ISO-27560]], the personal data fields are used to describe aspects of personal data as - type, identifier, optionality, being sensitive and being special category. In the DPV implementation, these are described as annotations or additional relations over the personal data instance.

Personal Data Type

This field MUST be present.

The type or category of personal data ('pii type' in [[ISO-27560]]), expressed in DPV using rdf:type, and optionally using concepts from the [[DPV-PD]] taxonomy. The value for this field must use a data category from DPV either through an explicit declaration i.e. using rdf:type or through an implicit definition e.g. [[DPV-PD]] taxonomy.

Personal data specified using [[DPV-PD]] concept

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": {
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasPersonalData": "dpv-pd:EmailAddress"
    }
}

Personal data specified with type explicitly declared using [[DPV-PD]] concept. The benefit of this approach is that it enables additional annotations such as a description of the data, as well as associating identifiers with the data category.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": {
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasPersonalData": {
            "@type": "dpv-pd:EmailAddress",
            "dct:description": "The customer's email address"
        }
    }
}

Personal Data Identifier

This field MAY be present.

The identifier representing the data values or instances e.g. within a database, expressed in DPV using dct:identifier.

Here, the identifier refers to a row ID within some internal database. The use of identifier in this case is to avoid exposing the actual email address within the consent record.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": {
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasPersonalData": {
            "@type": "dpv-pd:EmailAddress",
            "dct:identifier": "MDA5-hashed-email-address"
        }
    }
}

Personal Data Necessity

This field MAY be present.

The necessity or optionality of this data ('pii optional' in [[ISO-27560]]) for the processing, expressed in DPV using hasNecessity and one of the provided instances of Necessity. If this field is absent, it should be inferred as the data being necessary.

Here, the identifier refers to a row ID within some internal database. The use of identifier in this case is to avoid exposing the actual email address within the consent record.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": {
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasPersonalData": [{
            "@type": "dpv-pd:EmailAddress",
            "dpv:hasNecessity": "dpv:Required"
        }, {
            "@type": "dpv-pd:Name",
            "dpv:hasNecessity": "dpv:Optional"
        }]
    }
}

Necessity (or Optionality) can also be expressed at broader contexts, such as for the entire personal data handling instance. This has the advantage over [[ISO-27560]] in that some purpose or processing could also be stated to be necessary or optional. In such cases, the expressed necessity is to be applied to ALL concepts within that instance. In the below example, the first instance has both purpose (communication) and personal data (email) as required or necessary, and the second has both (marketing, name) as optional.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": [{
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasNecessity": "dpv:Required",
        "dpv:hasPurpose": "dpv:CommunicationManagement",
        "dpv:hasPersonalData": {"@type": "dpv-pd:EmailAddress"}
    }, {
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasNecessity": "dpv:Optional",
        "dpv:hasPurpose": "dpv:Marketing",
        "dpv:hasPersonalData": {"@type": "dpv-pd:Name"}
    }]
}

In the absence of a necessity statement, the default interpretation should be that the necessity is dpv:Required. In the below example, both instances have the necessity required even when only one of them explicitly declares it. As good practice, it is always better to specify the necessity explicitly to avoid confusion.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": [{
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasNecessity": "dpv:Required",
        "dpv:hasPurpose": "dpv:CommunicationManagement",
        "dpv:hasPersonalData": {"@type": "dpv-pd:EmailAddress"}
    }, {
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasPurpose": "dpv:Marketing",
        "dpv:hasPersonalData": {"@type": "dpv-pd:Name"}
    }]
}

Sensitive and Special Category

This field MAY be present.

Indicates whether the personal data is considered sensitive ('sensitive pii category' in [[ISO-27560]]), and separately whether it is also of special category ('special pii category' in [[ISO-27560]]). Declaring either in DPV is done using rdf:type with value SensitivePersonalData or SpecialCategoryPersonalData. Its absence indicates the data does not belong to either sensitive or special categories.

Being sensitive or special category is equivalent to defining it as the 'type' of data in DPV. Therefore, the notation for declaring type and sensitive is the same. In the below example, the first instance is sensitive, the second of special category, and the third is neither.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": {
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasPersonalData": [{
            "@type": ["dpv-pd:Location","dpv:SensitivePersonalData"],
            "dct:identifier": "The user's real-time GPS location"
        }, {
            "@type": ["dpv-pd:MedicalHealth","dpv:SpecialCategoryPersonalData"],
            "dct:identifier": "The user's health records from their local GP"
        }, {
            "@type": "dpv-pd:Email",
            "dct:identifier": "The user's provided email address"
        }]
    }
}

Processing Operations

This field MAY be present.

Indicates the processing operations or activities carried out over the specific personal data, and indicated using dpv:hasProcessing with instances of dpv:Processing. In [[ISO-27560]], this field also represents information about automated decision making - which is represented in DPV through the dpv:AutomationOfProcessing concepts and associated with dpv:hasProcessingAutomation, as well as large scale of processing which is represented through dpv:ScaleOfProcessing and associated using dpv:hasScale.

Processing operations specified by using the DPV taxonomy, and associated with personal data and purposes using PersonalDataHandling. In this example, the email address is collected, stored, and used.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": [{
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasPurpose": "dpv:CommunicationManagement",
        "dpv:hasPersonalData": {"@type": "dpv-pd:EmailAddress"},
        "dpv:hasProcessing": ["dpv:Collect", "dpv:Store", "dpv:Use"]
    }]
}

Processing specified with automated decision making, profiling, and large scale of processing. In DPV, profiling is a processing operation, whereas automated decision making and scale of processing are separate concepts.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": [{
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasPurpose": "dpv:CommunicationManagement",
        "dpv:hasPersonalData": {"@type": "dpv-pd:EmailAddress"},
        "dpv:hasProcessing": ["dpv:Collect", "dpv:Store", "dpv:Use"],
        "dpv:hasProcessingAutomation": "dpv:FullyAutomatedProcessing",
        "dpv:hasScale": "dpv:LargeScaleProcessing"
    }]
}

Another similar example to showcase the range of processing context concepts in DPV - here the processing is a semi-automated decision making with human involvement, and involves a small scale of processing for a large scale of data subjects.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": [{
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasPurpose": "dpv:CommunicationManagement",
        "dpv:hasPersonalData": {"@type": "dpv-pd:EmailAddress"},
        "dpv:hasProcessing": ["dpv:Collect", "dpv:Store", "dpv:Use", "dpv:Profiling"],
        "dpv:hasProcessingAutomation": "dpv:SemiAutomatedProcessing",
        "dpv:hasHumanInvolvement": "dpv:HumanInvolvementForOversight",
        "dpv:hasScale": ["dpv:SmallScaleProcessing", "dpv:LargeScaleOfDataSubjects"]
    }]
}

Another similar example with more specific associations between processing operations and contextual information such as full automation, large scale, and no human involvement.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": [{
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasPurpose": "dpv:CommunicationManagement",
        "dpv:hasPersonalData": {"@type": "dpv-pd:EmailAddress"},
        "dpv:hasProcessing": [{
            "@type": "dpv:Use",
            "dpv:hasScale": ["dpv:LargeScaleProcessing", "dpv:LargeScaleOfDataSubjects"],
            "dpv:hasProcessingAutomation": "dpv:FullyAutomatedProcessing",
            "dpv:hasHumanInvolvement": "dpv:NotApplicable"
        }]
    }]
}

Data Source(s)

This field MAY be present.

This field represents the source of data being processed. In [[ISO-27560]], this field is called collection method and can be about The data provided by or observed from activities of the data subjects, be inferred from existing data, or be collected from another entity or third party. In DPV, this information is represented using dpv:DataSource and associated using dpv:hasDataSource.

Concepts within the DPV taxonomy have an exact meaning - for example data being obtained through observation should not be stated as being collected, but as observed - even if the data source is still the same data subject. Therefore, it is best to separate the data source entity and the processing operation.

The following examples state the data subject as a data source as stated in [[ISO-27560]] for direct data collection, indirect obervation or derivation, and inferred.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": [{
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasPurpose": "dpv:CommunicationManagement",
        "dpv:hasPersonalData": {"@type": "dpv-pd:Location"},
        "dpv:hasDataSource": [{
            "@type": "dpv:DataSubject",
            "dpv:hasProcessing": "dpv:Collect"
        }, {
            "@type": "dpv:DataSubject",
            "dpv:hasProcessing": "dpv:Observe"
        }, {
            "@type": "dpv:DataSubject",
            "dpv:hasProcessing": ["dpv:Collect", "dpv:Derive"],
            "dpv:hasPersonalData": "dpv-pd:IPAddress"
        }, {
            "@type": "dpv:DataSubject",
            "dpv:hasProcessing": "dpv:Infer",
            "dpv:hasPersonalData": "dpv-pd:BrowserBehavior"
        }
    }]
}

The following example states non- data subject entities as a data source as stated in [[ISO-27560]], where the entities are of type Processor and Third Party respectively. The example also shows how processing operations can directly specify their data sources.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": [{
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasPurpose": "dpv:CommunicationManagement",
        "dpv:hasPersonalData": {"@type": "dpv-pd:Location"},
        "dpv:hasProcessing": [{
            "@type": "dpv:Transfer",
            "dpv:hasDataSource": {
                "@type": "dpv:DataProcessor",
                "@id": "https://example.com/Acme"
            }
        }, {
            "@type": ["dpv:Collect", "dpv:Acquire"],
            "dpv:hasDataSource": {
                "@type": "dpv:ThirdParty",
                "@id": "https://example.com/Beta"   
            }
        }]
    }]
}

The following example shows how data sources can be specified in terms of devices and technologies using concepts from (work-in-progress) [[DPV-TECH]].

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": [{
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasPurpose": "dpv:CommunicationManagement",
        "dpv:hasPersonalData": {"@type": "dpv-pd:Location"},
        "dpv:hasDataSource": {
            "@type": "dpv:DataSubject",
            "dpv:hasProcessing": "dpv:Collect",
            "dpv:isImplementedUsingTechnology": {
                "@type": "tech:Device",
                "tech:hasCommunicationMechanism": ["tech:GPS", "tech:WiFi"]
            }
        }
    }]
}

Storage Condition(s)

This field MUST be present.

Indicates information about the storage of personal data such as regarding its duration, location, and erasure, represented using dpv:StorageCondition and associated using dpv:hasStorageCondition. The existence of Storage Condition implies storing data as a processing operation. In [[ISO-27560]], this information is represented through two fields - storage locations and retention period - both of which are required to be present.

The following example shows how information about storage conditions can be associated using the DPV concepts. It associates three conditions with the personal data handling instance representing location, duration, and retention.

The first example shows locations expressed using the DPV-Locations extension (work in progress), and indicate that data will be stored in Ireland, France, and Germany - with another example showing EU as a (jurisdiction-based) location. The other examples show how non-geopolitical locations can be represented using DPV.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": [{
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasPurpose": "dpv:CommunicationManagement",
        "dpv:hasPersonalData": {"@type": "dpv-pd:Location"},
        "dpv:hasDataStorageCondition": [{
            "@type": "dpv:StorageLocation",
            "dpv:hasLocation": ["loc:IE", "loc:FR", "loc:DE"],
        }, {
            "@type": "dpv:StorageLocation",
            "dpv:hasLocation": "loc:EU"
        }, {
            "@type": "dpv:StorageLocation",
            "dpv:hasLocation": "dpv:WithinDevice"
        }, {
            "@type": "dpv:StorageLocation",
            "dpv:hasLocation": {
                "@type": ["dpv:FederatedLocation", 
                    "dpv:WithinDevice", "dpv:CloudLocation"]
            }
        }]
    }]
}

The following example shows the duration associated with storage of data. Duration implies that data will be removed or erased after the duration.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": [{
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasPurpose": "dpv:CommunicationManagement",
        "dpv:hasPersonalData": {"@type": "dpv-pd:Location"},
        "dpv:hasStorageCondition": [{
            "@type": "dpv:StorageDuration",
            "rdfs:comment": "6 Months using ISO 8601",
            "dpv:hasDuration": "P6M",
            "dpv:hasDuration": {
                "@type": ["dpv:TemporalDuration", "xsd:duration"],
                "rdf:value": "P6M"
            }
        }, {
            "@type": "dpv:StorageDuration",
            "rdfs:comment": "duration lapsing at the end of year",
            "dpv:hasDuration": "2023-12-31",
            "dpv:hasDuration": {
                "@type": ["dpv:UntilTimeDuration", "xsd:date"],
                "rdf:value": "2023-12-31"
            }
        }, {
            "@type": "dpv:StorageDuration",
            "dpv:hasDuration": {
                "@type": "dpv:FixedOccurencesDuration",
                "rdf:value": "12"
            }
        }, {
            "@type": "dpv:StorageDuration",
            "dpv:hasDuration": {
                "@type": "dpv:UntilEventDuration",
                "rdf:value": "Account Closure"
            }
        }]
    }]
}

The following example shows erasure as a distinct condition separate from the storage duration. In [[ISO-27560]], the field for retention period refers to both the retention and erasure of data. In DPV, this is separated as data may get scheduled for deletion and may remain stored for a duration before its actual erasure. In the example, the data is to be stored for 6 months and then deleted by 1 month following this period.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": [{
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasPurpose": "dpv:CommunicationManagement",
        "dpv:hasPersonalData": {"@type": "dpv-pd:Location"},
        "dpv:hasStorageCondition": [{
            "@type": "dpv:StorageDuration",
            "dpv:hasDuration": "P6M"
        }, {
            "@type": "dpv:StorageDeletion",
            "dpv:hasDuration": "P1M"
        }]
    }]
}

Processing Condition(s)

This field MAY be present.

Indicates information about conditions regarding the processing operations, such as regarding its duration and location, represented using dpv:ProcessingCondition and associated using dpv:hasProcessingCondition. Given that storing data is a specific type of processing operation, this field is useful for other processing activities such as collection of data. In [[ISO-27560]], the field only relates to processing locations.

The examples show various combinations of processing location and duration, using the same concepts and patterns as those used in the examples for Storage Condition. In addition, it also shows the possibility to express the frequency of processing using dpv:Frequency and associated using dpv:hasFrequency. To express combinations of duration, location, and frequencies - their respective concepts can be combined as shown explicitly last example.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": [{
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasPurpose": "dpv:CommunicationManagement",
        "dpv:hasPersonalData": {"@type": "dpv-pd:Location"},
        "dpv:hasDataProcessingCondition": [{
            "@type": "dpv:ProcessingLocation",
            "dpv:hasLocation": "dpv:WithinDevice",
        }, {
            "@type": "dpv:ProcessingLocation",
            "dpv:hasLocation": "loc:EU"
        }, {
            "@type": "dpv:ProcessingDuration",
            "dpv:hasDuration": "P6M"
        }, {
            "@type": "dpv:ProcessingFrequency",
            "dpv:hasFrequency": "dpv:SingularFrequency"
        }, {
            "@type": "dpv:ProcessingFrequency",
            "dpv:hasFrequency": "dpv:ContinousFrequency"
        }, {
            "@type": ["dpv:ProcessingLocation", 
                    "dpv:ProcessingDuration", "dpv:ProcessingFrequency"],
            "dpv:hasLocation": "dpv:WithinDevice",
            "dpv:hasDuration": "P1D",
            "dpv:hasFrequency": "dpv:SporadicFrequency"
        }]
    }]
}

Geographic Restriction(s)

This field MAY be present.

Geographic restrictions are defined in [[ISO-27560]] as restrictions related to geo-locations or jurisdictions. While DPV prefers a declarative interpretation where, for e.g., if processing location is mentioned as EU then it implies that processing will only take place within EU since no other locations are mentioned. If the intention is to explicitly state this as a restriction, it can utilise the dpv:Rule concept which provides (simplified) Permissions, Prohibitions, and Obligations. For further expressivity or complexity, specifications such as [[[odrl-model]]] should be considered.

Note that while [[ISO-27560]] only considers restrictions over geographic locations for processing (including storing), DPV (and ODRL)support specifying information and restrictions over a much wider range of concepts. In theory, restrictions can be expressed over any concept or combination of concepts.

The below example expresses that data must be stored within EU. Note that DPV's concepts do not support expressing negations i.e. we cannot state data must not be stored within non-EU locations. Also note the ambiguity in interpreting DPV's obligation as meaning either data must only be stored in EU or must at least be stored in EU (in addition to elsewhere). An alternative to this is to utilise an appropriate vocabulary such as [[ODRL]] - as in the second rule below, or as a last resort to use plain text - which is less desirable.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": {
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasRule": [{
            "@type": "dpv:Obligation",
            "dpv:hasLocation": "loc:EU",
            "dpv:hasProcessing": "dpv:Store",
        }, {
            "@type": ["dpv:Prohibition", "odrl:Prohibition"],
            "rdfs:comment": "Use ODRL concepts here"
        }, {
            "@type": "dpv:Prohibition",
            "dpv:hasProcessing": "dpv:Store"
            "dct:description": "Storing in Non-EU locations is NOT allowed"
        }]
    }
}

Data Controller(s)

This field MUST be present.

Indicates the Data Controllers (pii controllers in [[ISO-27560]]) responsible for the specified processing activities, expressed in DPV using hasDataController with instances of DataController.

Note that the notion of a 'Controller' is regarding accountability, and does not necessarily correlate with who performs the processing or has access to data - for example in GDPR. To indicate who performs the processing, DPV provides dpv:isImplementedByEntity.

Information about the Data Controller, such as its name or address, is described through the Entity Fields later in the document based on a similar structure in [[ISO-27560]].

The below examples show processing where a single entity acts as the data controller for all of the processing (represented using PersonalDataHandling, and extends it to show how different controllers can be associated for different processing activities.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": [{
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasPurpose": "dpv:IdentityVerification",
        "dpv:hasDataController": "ex:Acme"
    }, {
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasPurpose": "dpv:ServiceProvision",
        "dpv:hasDataController": "ex:Beta"
    }]
}

In case of multiple controller, these can be stated as a list of controllers, or - in the case of GDPR - be also declared as a joint controller using dpv:JointDataController.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": {
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasPurpose": "dpv:IdentityVerification",
        "dpv:hasDataController": ["ex:Acme", "ex:Beta"]
    }
}

Legal Basis

This field MAY be present.

The legal basis (lawful basis in [[ISO-27560]] for processing of personal data. Though the lawful basis for a consent record would always be consent, the presence of the field enables extensions of the record to other legal bases (e.g. contract) in the future. In DPV, the legal basis is associated using hasLegalBasis with a concept from the LegalBasis taxonomy.

In addition to defining consent as a legal basis, DPV also provides a taxonomy to express various categories of consent - such as InformedConsent and ExpressedConsent which provide a more granular and accurate definition of the legal basis being utilised. For expressing specific consent based on specific jurisdictions and regulations, the appropriate extended concept should be used, for e.g. [[DPV-GDPR]] defines consent as a legal basis based on the specific clauses and requirements of the [[GDPR]].

Consent is directly associated with the first PersonalDataHandling as the legal basis. Such use is commonly interpreted as meaning consent according to some obligations and requirements to be considered valid, for example being informed and expressed rather than assumed. The second PersonalDataHandling uses the specific type of consent required which clearly indicates which requirements it is expected to fulfil to be considered valid.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": [{
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasLegalBasis": "dpv:Consent"
    }, {
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasLegalBasis": "dpv:ExplicitlyExpressedConsent"
    }]
}

To indicate that a GDPR-defined consent is being used as the legal basis, the [[DPV-GDPR]] concept is used by itself or in combination with a core consent type to explicitly indicate the level of consent. Note that in the second example, [[DPV-GDPR]] already defines A9-2-a as a subtype of dpv:ExplicitlyExpressedConsent, so the combined use does not lead to contradictions.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": [{
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasLegalBasis": "dpv-gdpr:A6-1-a"
    }, {
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasLegalBasis": ["dpv:ExplicitlyExpressedConsent", "dpv-gdpr:A9-2-a"]
    }]
}

Recipients

This field MUST be present.

Indicates the recipients of personal data associated with the specific processing activities, expressed as dpv:Recipient and associated using dpv:hasRecipient. In [[ISO-27560]], this field is only limited to Recipients who are Third Parties, which excludes the Data Controllers and Processors. In DPV, recipients can be any of Data Controllers, or Processors, or Third Parties.

Note that recipients can be specific entities i.e. their identity is known, or groups or categories of entities - for example as in GDPR's Article 13-1e. However, [[ISO-27560]] only considered explicitly indicated third parties for the recipients field.

In [[ISO-27560]], the recipient field is also associated with information regarding the geo-location of data being transferred to the recipient third party's and whether this constitutes a jurisdictional change. To represent this in DPV, the location of the transfer should be indicated within the processing information along with the recipient entity. The jurisdiction can also be represented in the same context - to indicate the transfer to that jurisdiction, or it can be specified in association with the recipient entity.

Recipients can be indicated separately for the entirety of PersonalDataHandling which indicates all data is being received by the specified recipient.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": {
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasPersonalData": ["dpv-pd:Email", "dpv-pd:Name"],
        "dpv:hasDataController": "ex:Acme",
        "dpv:hasRecipient": "ex:Beta"
    }
}

Recipients can be also be indicated contextually within each PersonalDataHandling or Processing to indicate the recipient entity for that specific context - which allows to separate the recipients based on what data and processing they are associated with. In the below example, the first activity has Acme receiving the Email, and the second activity has Beta collecting the Name and transferring it to Gamma.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": [{
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasPersonalData": "dpv-pd:Email",
        "dpv:hasRecipient": "ex:Acme"
    }, {
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasPersonalData": "dpv-pd:Name",
        "dpv:hasProcessing": [{
            "@type": "dpv:Collect",
            "dpv:hasRecipient": "ex:Beta"
        }, {
            "@type": "dpv:Transfer",
            "dpv:hasRecipient": "ex:Gamma"
        }
    }
}

To specify the locations and jurisdictions of recipients, the appropriate DPV concepts and relations are used. In the below example, the first activity states Acme is a Recipient and also the Data Controller whose location is Ireland, and the second activity states that the transfer to Beta has location France and jurisdiction EU.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": [{
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasPersonalData": "dpv-pd:Email",
        "dpv:hasDataController": "ex:Acme",
        "dpv:hasRecipient": {
            "@type": "dpv:Recipient",
            "@id": "ex:Acme",
            "dpv:hasLocation": "loc:IE"
        }
    }, {
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasPersonalData": "dpv-pd:Name",
        "dpv:hasProcessing": {
            "@type": "dpv:Transfer",
            "dpv:hasRecipient": "ex:Beta",
            "dpv:hasLocation": "loc:France",
            "dpv:hasJurisdiction": "loc:EU"
        }
    }]
}

Consent Change & Withdrawal

This field MUST be present.

Indicates the information on how the data subject can change or withdraw the specified consent, expressed using processes part of ConsentManagement and associated using hasConsentManagement. To indicate how the data subject should take action, the relation isExercisedAt is to be used.

In [[ISO-27560]], this field is specific to the withdrawal method or a link to the information on withdrawal. It also allows this field to be associated with the Data Controller (in the Party/Entity section) rather than per-processing activity.

To express how the data subject can withdraw consent.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": {
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasConsentManagement": {
            "@type": "dpv:WithdrawConsent",
            "dpv:isExercisedAt": "https://example.com/manage-consent"
        }
    }
}

To express how the data subject can change, withdraw, or (re-)confirm their existing consent. Here, ChangeConsent is the broader consent and includes processes to withdraw and reaffirm consent.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": {
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasConsentManagement": {
            "@type": "dpv:ChangeConsent",
            "dpv:isExercisedAt": "https://example.com/manage-consent"
        }
    }
}

To express how the data subject can provide and change their consent.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": {
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasConsentManagement": [{
            "@type": "dpv:ProvideConsent",
            "dpv:isExercisedAt": "https://example.com/manage-consent"
        }, {
            "@type": "dpv:ChangeConsent",
            "dpv:isExercisedAt": "https://example.com/manage-consent"
        }]
    }
}

Jurisdiction(s)

This field MUST be present.

Indicates the applicable jurisdiction for the processing indicated within the receipt. The acknolwedgement of jurisdiction(s) is necessary to convey applicable laws and requirements regarding consent validity and applicable rights as well as indicating the obligations on parties involved. To indicate the jurisdiction, the concept Location is to be associated using hasJurisdiction.

In [[ISO-27560]], this field can also be associated with the Data Controller (in the Party/Entity section) rather than per-processing activity.

To express how the data subject can withdraw consent.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": {
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasJurisdiction": "loc:EU"
    }
}

Rights

This field MUST be present.

Indicates the applicable rights and provides information on how to avail or exercise them. The rights are indicated using DataSubjectRight and associated using hasRight. To indicate how to exercise them, the relation isExercisedAt is to be used. To indicate provision of information regarding rights exercise, the concept RightExerciseNotice is to be used and associated using hasNotice.

In [[ISO-27560]], this field is optional, and is used to provide a link to information on how to exercise rights. It also allows this field to allow changes to the consent conditions such as the retention period. In [[ISO-27560]], this field can also be associated with the Data Controller (in the Party/Entity section) rather than per-processing activity.

Expressing rights exercise information using DPV is done using the DataSubjectRight instance and associated using hasRight. The contents of this information can include annotations, such as using dct:title to summarise the right, and dpv:isExercisedAt to indicate how/where it is to be exercised.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": {
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasRight": {
            "@type": "dpv:DataSubjectRight",
            "dct:title": "Right to Obtain Information",
            "dct:description": "To obtain information, go to the specified link",
            "dpv:isExercisedAt": "https://example.com/rights"
        }
    }
}

To indicate specific rights under a particular jurisdiction or regulation, the appropriate concepts have to be declared and used. In this example, GDPR's Right to Withdraw Consent (Art.7-3) and Right to Data Portability (Art.20) are described with information on how to exercise them. This can be done with explicit acknolwedgement of GDPR as the regulation using dpv:hasApplicableLaw, and EU as the jurisdiction using hasJurisdiction.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": {
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasRight": [{
            "@type": ["dpv:DataSubjectRight", "dpv-gdpr:A7-3"],
            "dct:title": "Right to Withdraw Consent",
            "dpv:isExercisedAt": "https://example.com/rights",
            "dpv:hasApplicableLaw": "dpv-gdpr:GDPR",
            "dpv:hasJurisdiction": "loc:EU"
        }, {
            "@type": ["dpv:DataSubjectRight", "dpv-gdpr:A20"],
            "dct:title": "Right to Data Portability",
            "dpv:isExercisedAt": "https://example.com/rights",
            "dpv:hasApplicableLaw": "dpv-gdpr:GDPR",
            "dpv:hasJurisdiction": "loc:EU"
        }]
    }
}

The same or similar right can be applicable under multiple jurisdictions and/or regulations. In this example, the Right to Withdraw Consent is expressed as being applicable under multiple jurisdictions using hasJurisdiction.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": {
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasRight": {
            "@type": "dpv:DataSubjectRight",
            "dct:title": "Right to Withdraw Consent",
            "dpv:isExercisedAt": "https://example.com/rights",
            "dpv:hasJurisdiction": ["loc:EU", "loc:EEA"]
        }
    }
}

To indicate information required for exercise of rights, DPV's existing properties such as hasPersonalData and necessity concepts such as Required can be used. This example shows the right to data portability requires collecting an email for exercising it.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": {
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasRight": {
            "@type": ["dpv:DataSubjectRight", "dpv-gdpr:A20"],
            "dct:title": "Right to Data Portability",
            "dpv:isExercisedAt": "https://example.com/rights",
            "dpv:hasPersonalDataHandling": {
                "@type": "dpv:PersonalDataHandling",
                "dpv:hasPersonalData": "dpv:Email",
                "dpv:hasProcessing": "dpv:Collect",
                "dpv:hasPurpose": "dpv:FulfilmentOfObligation",
                "dpv:hasNecessity": "dpv:Required"
} } } }

To indicate what will be the resulting action from exercising the right, existing concepts and external vocabularies such as schema.org or DCAT can be used. This example shows the resulting obligation from exercising the right to data portability being the provision of a dataset containing collected personal data.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": {
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasRight": {
            "@type": ["dpv:DataSubjectRight", "dpv-gdpr:A20"],
            "dct:title": "Right to Data Portability",
            "dpv:isExercisedAt": "https://example.com/rights",
            "dpv:hasPersonalDataHandling": {
                "@type": "dpv:PersonalDataHandling",
                "dpv:hasPersonalData": "dpv:Email",
                "dpv:hasProcessing": "dpv:Collect",
                "dpv:hasPurpose": "dpv:FulfilmentOfObligation",
                "dpv:hasNecessity": "dpv:Required"
            },
            "dpv:hasObligation": {
                "@type": "schema:SendAction",
                "schema:recipient": "dpv:DataSubject",
                "schema:object": {
                    "@type": "schema:Dataset",
                    "dpv:hasPersonalData": "dpv:CollectedData",
                    "schema:distribution": {
                        "schema:encodingFormat": "iana:CSV",

} } } } } }

Service(s)

This field MAY be present.

Indicates the services the described processing activities are a part of or assist with, expressed as an instance of dpv:Service and associated using dpv:hasService.

In [[ISO-27560]], a Service can be as broad or granular as desired. A service is related to a purpose by providing a context through which the specific purpose can be understood within their context, and also to enable related purposes and activities to be associated and explained with a common service being provided.

To indicate processing activities are associated with a specific service, an instance of dpv:Service is associated using dpv:hasService. In this example, the expression of a service provides important context for the interpretation of the purpose of dpv:ServiceProvision.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": {
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasPurpose": "dpv:ServiceProvision",
        "dpv:hasService": {
            "@type": "dpv:Service",
            "dct:title": "Movie Streaming"
        }
    }
}

Code of conduct(s)

This field MAY be present.

Indicates the applicability of a Code of Conduct for the specified processing activity. A code of conduct is a voluntary set of rules and responsibilities undertaken by an organisation. It is indicated using an instance of dpv:CodeOfConduct and associated using dpv:hasOrganisationalMeasure.

In [[ISO-27560]], this field is described as providing information regarding the name of the code of conduct and a publicly accessible reference to it. A code of conduct can also be associated with the Data Controller (in the Party/Entity section) rather than per-processing activity.

To express the code of conduct applicable to processing.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": {
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasOrganisationalMeasure": {
            "@type": "dpv:CodeOfConduct",
            "dct:title": "Code of Conduct on Processing Personal Data",
            "schema:url": "https://example.com/CoC"
        }
    }
}

Impact assessment(s)

This field MAY be present.

Indicates the existence of an Impact Assessment for the specified processing activity. An impact assessment in this record refers to the impact of the specified processing activities on the data subject. Impact assessments are indicated using instances of dpv:ImpactAssessment and associated using dpv:hasAssessment. DPV provides concepts for specific types of impact assessments, such as dpv:PIA for Privacy Impact Assessment and dpv:DPIA for Data Protection Impact Assessment.

In [[ISO-27560]], this field is limited to assessments of privacy risks and potential impacts of "non-compliance" on the data subjects, whereas in common practice assessments such as PIA and DPIA concern the impact of the processing on the data subject - which is what DPV and this specification considers. Impact assessments can also be associated with the Data Controller (in the Party/Entity section) rather than per-processing activity.

To express an impact assessment applicable for the processing.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": {
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasAssessment": {
            "@type": "dpv:DPIA",
            "schema:url": "https://example.com/DPIA"
        }
    }
}

Entity Fields

[[ISO-27560]] refers to Entity as Party.

Entities are expressed using instances of dpv:Entity and associated using dpv:hasEntity.

Field	Cardinality	DPV Concept	DPV Property
Name	1..*	N/A	dpv:hasName
Identifier	1..*	N/A	dpv:hasIdentifier
Role	1..*	dpv:DataController, dpv:DataProcessor, dpv:ThirdParty, dpv:Authority, dpv:DataSubject	rdf:type, dpv:hasDataController, dpv:hasDataProcessor, dpv:hasThirdParty, dpv:hasAuthority, dpv:hasDataSubject
Contact	1..*	schema:ContactPoint	schema:contactPoint
Postal Address	1..*	schema:PostalAddress	schema:contactPoint
Email	0..*	N/A	schema:email
Phone	0..*	N/A	schema:telephone
URL	0..*	N/A	schema:url

Name

This field MUST be present.

Indicates the legal name and identity of the Entity, expressed using dpv:hasLegalName and a string.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasEntity": {
        "@type": "dpv:Entity",
        "dpv:hasName": "Example Inc."
    }
}

DPV provides a taxonomy of different entity types, such as organisations, which can also be used to indicate what the entity is. In this example, the entity is declared to be a non-profit organisation.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasEntity": {
        "@type": "dpv:NonProfitOrganisation",
        "dpv:hasName": "Example Inc."
    }
}

Identifier

This field MUST be present.

Indicates the unique identifier for the entity within the record. In linked data and semantic web methods of expressing information, the IRI already acts as an unique identifier. To support interoperability, the IRI identifier MUST be declared explicitly using dpv:hasIdentifier. To denote other (unique or otherwise) identifiers as a reference to the entity, dct:identifier should be used.

In this specification and in [[ISO-27560]], the (IRI) identifier is used to associate the entity with specific processing roles, which is described in the next section.

The IRI of the entity is an identifier through which it can be uniquely identified. In this example, the entity has an id field which specifies its unique identifier, which is explicitly declared also using dpv:hasIdentifier to enable interoperability when converting between formats and schemas.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasEntity": {
        "@type": "dpv:Entity",
        "@id": "https://example.com/AcmeInc",
        "dpv:hasIdentifier": "https://example.com/AcmeInc"
    }
}

In this example, the entity has another identifier other than its IRI which should be considered as the unique identifier to identify this entity. It is therefore associated using dpv:hasIdentifier while the IRI is declared as an alternate identifier using dct:identifier

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasEntity": {
        "@type": "dpv:Entity",
        "@id": "https://example.com/AcmeInc",
        "dpv:hasIdentifier": "IE-0760c9ba",
        "dct:identifier": "https://example.com/AcmeInc"
    }
}

In this example, the entity's tax registration number is indicated as an additional identifier, with an explicit declaration of its meaning by using schema:PropertyValue. The example also shows the same information expressed using an appropriate domain specific ontology such as fibo:TaxIdentifier - as best practice.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasEntity": {
        "@type": "dpv:Entity",
        "@id": "https://example.com/AcmeInc",
        "dpv:hasIdentifier": [{
            "@type": "schema:PropertyValue",
            "name": "Tax Identifier",
            "value": "IE-0760c9ba"
        }, {
            "@type": "fibo:TaxIdentifier",
            "fibo:hasTextValue": "IE-0760c9ba"
        }]
    }
}

Role

This field MUST be present.

Indicates the role of the entity within the process activities, indicated using rdf:type and an appropriate role such as dpv:DataController, dpv:DataProcessor, dpv:ThirdParty, dpv:Authority, and dpv:DataSubject.

In [[ISO-27560]], the entity (party) fields are separate from the processing section and therefore the role of the entity is expressed separate from processing. In DPV, the role MUST be expressed contextually within the processing fields by using an appropriate property e.g. dpv:hasDataController and the identifier of the entity. Optionally, the entity description field can also contain an explicit acknowledgement of the role by stating the entity is of type e.g. dpv:DataController.

The role of the entity can be declared contextually using properties such as dpv:hasDataController and dpv:hasDataSubject within the processing section, and explicitly using rdf:type within entity section. This example shows both uses for data controller and data subject entities. The (IRI) identifier of the entity is used within the processing section which points to the declared information within the entities section. The identifier for the data subject is a local identifier within the record and known to the data controller to minimise identifying information within the record.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": {
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasDataController": "ex:Acme",
        "dpv:hasDataSubject": "0760c9ba"
    },
    "dpv:hasEntity": [{
        "@id": "ex:Acme",
        "@type": "dpv:DataController"
    }, {
        "@id": "0760c9ba",
        "@type": "dpv:DataSubject"
    }]
}

Contact

This field MUST be present.

Indicates the contact for an entity for communication purposes, indicated using schema:contactPoint and an instance of schema:ContactPoint.

NOTE: As in [[ISO-27560]], this field MUST be present for all entities EXCEPT data subjects as in a record it may not be necessary to record the contact for data subjects. This follows best practices regarding data minimisation and purpose limitation.

The entitie's contact point expressed using schema:contactPoint and an instance of schema:ContactPoint. In this example, the contact point is a 'direct message' service for the entity's social media handle.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasEntity": {
        "@type": "dpv:Entity",
        "schema:contactPoint": {
            "@type": "schema:contactPoint",
            "schema:contactType": "DM",
            "url": "https://example.com/social-media/DM"
        }
    }
}

Postal Address

This field MUST be present.

Indicates the potal address of the entity, expressed using schema:address and an instance of schema:PostalAddress.

NOTE: As in [[ISO-27560]], this field MUST be present for all entities EXCEPT data subjects as in a record it may not be necessary to record the postal address of data subjects. This follows best practices regarding data minimisation and purpose limitation.

The entitie's postal address expressed using schema:contactPoint and an instance of schema:PostalAddress.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasEntity": {
        "@type": "dpv:Entity",
        "schema:contactPoint": {
            "@type": "schema:PostalAddress",
            "schema:streetAddress": "Example Avenue, Example, 000-000"
        }
    }
}

Email

This field MAY be present.

Indicates the email of the entity, expressed using schema:email.

The entitie's email expressed using schema:email.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasEntity": {
        "@type": "dpv:Entity",
        "schema:contactPoint": {
            "@type": "schema:ContactPoint",
            "schema:email": "[email protected]"
        }
    }
}

Phone

This field MAY be present.

Indicates the telephone of the entity, expressed using schema:telephone.

The entitie's email expressed using schema:telephone.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasEntity": {
        "@type": "dpv:Entity",
        "schema:contactPoint": {
            "@type": "schema:ContactPoint",
            "schema:telephone": "+00-000-000"
        }
    }
}

URL

This field MAY be present.

Indicates the url of the entity, expressed using schema:url. The type of the page can be expressed using appropriate concepts, such as dpv:PrivacyNotice.

The entity's url expressed using schema:url.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasEntity": {
        "@type": "dpv:Entity",
        "schema:url": "https://example.com/"
    }
}

The entity's privacy notice expressed using schema:PropertyValue and dpv:PrivacyNotice. While notices can also be associated using dpv:hasNotice, it is suggested to use schema:url in this case for consistency in associating urls.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasEntity": {
        "@type": "dpv:Entity",
        "schema:url": {
            "@type": "schema:PropertyValue",
            "name": "dpv:PrivacyNotice"
            "https://example.com/privacy-policy"
    }
}

Consent Event Fields

[[ISO-27560]] contains 5 fields to describe events associated with consent.

Field	Cardinality	DPV Concept	DPV Property
Consent Type	1..*	dpv:Consent taxonomy	dpv:hasLegalBasis
Consent State	1..*	dpv:ConsentStatus taxonomy	dpv:hasConsentStatus
Event Time	1..*	N/A	dpv:isIndicatedAtTime
Event Duration	1..*	dpv:Duration	dpv:hasDuration
Expression by Entity	1..*	dpv:Entity	dpv:isIndicatedBy
Expression Method	0..*	N/A	dpv:hasIndicationMethod

Consent Type

This field MUST be present.

Indicates the type of consent (e.g. Implicit, Expressed, Explicit) expressed by the data subject. In [[ISO-27560]], this field is called event type.

In DPV, dpv:ConsentType represents consent types to be used as a legal basis (dpv:hasLegalBasis) and has the following different types: dpv:InformedConsent and dpv:UninformedConsent to indicate whether the consent is informed or not. Informed consent is further specialised as: dpv:ImpliedConsent for consent indicated through an implied or indirect action (e.g. merely browsing a website), dpv:ExpressedConsent for consent indicated through a direct expressed action (e.g. a checkbox), and dpv:ExplicitlyExpressedConsent for consent indicated through a direct action concerning solely the consent in context.

Consent types are also dependent on jurisdictional requirements, such as GDPR's various consent types. These can be represented by expanding on the relevant DPV concepts. For GDPR, the following consent types are provided in [[DPV-GDPR]]: dpv-gdpr:A6-1-a expressed consent and dpv-gdpr:A9-2-a explicit consent.

Best practice for choosing approprite consent types concern expressing the correct legal basis for a specific jurisdiction where possible (e.g. GDPR A.6-1a) or to indicate the type of consent (e.g. Expressed Consent) where the jurisdiction is explicitly provided or is understood from available context. Following this, the most appropriate consent types for most cases would be dpv:ExpressedConsent and dpv:ExplicitlyExpressedConsent.

This example shows the consent type dpv:ExplicitlyExpressedConsent used as a legal basis. Since no jurisdiction is specified here, the interpretation of its validity depends on external context, or alternatively it indicates the interpretation of consent validity should be as per the intpretation of "explicitly expressed" in whatever jurisdiction is chosen.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": {
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasLegalBasis": "dpv:ExplicitlyExpressedConsent"
    }
}

This example shows two uses of consent types both concerning dpv:ExplicitlyExpressedConsent. The first explicitly declares the jurisdiction as EU and the law being applicable as GDPR, and the second uses the GDPR clause Art.9-2a which indicates explicitly expressed consent. The advantage of the first approach is that the same consent type (explicitly expressed consent) can be used with different jurisdictions and laws, and the advantage of the second approach is in explicitly linking to a legal clause which is desirable for compliance evaluation and demonstration processes.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasPersonalDataHandling": [{
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasLegalBasis": "dpv:ExplicitlyExpressedConsent",
        "dpv:hasJurisdiction": "loc:EU",
        "dpv:hasApplicableLaw": "dpv-gdpr:GDPR"
    }, {
        "@type": "dpv:PersonalDataHandling",
        "dpv:hasLegalBasis": "dpv-gdpr:A9-2-a"
    }]
}

Consent State

This field MUST be present.

Indicate the state or status of consent reflecting its applicability or suitability to be used as a legal basis to justify the specified processing. In DPV, it is represented through dpv:ConsentStatus and associated using dpv:hasConsentStatus. Instances of consent states represent specific events concerning the use of consent as a legal basis, e.g. requesting consent, giving consent, withdrawing consent. Each event may have corresponding processes, such as giving consent enables the processing to take place and withdrawing consent stops the processing taking place.

DPV provides several states broadly categorised under those valid for processing and those that are not. These are:

The consent states that are considered valid for processing (dpv:ConsentStatusValidForProcessing) are: dpv:ConsentGiven, dpv:RenewedConsentGiven.
The consent states that are NOT considered valid for processing (dpv:ConsentStatusInvalidForProcessing) are: dpv:ConsentUnknown, dpv:ConsentRequested, dpv:ConsentRequestDeferred, dpv:ConsentRefused, dpv:ConsentWithdrawn, dpv:ConsentExpired, dpv:ConsentTerminated, dpv:ConsentInvalidated.

This example specifies the association of consent states within the consent record. It shows that consent has been given for processing that had explicitly expressed consent as its legal basis. It can be inferred that the given consent is expected to be of type "explicitly expressed". Note that this example does not show when the consent was given as well as any other contextual information (e.g. expressed where, how).

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasLegalBasis": "dpv:ExplicitlyExpressedConsent",
    "dpv:hasConsentStatus": "dpv:ConsentGiven"
}

This example shows that consent has been given for processing witha declaration that it is of type explicitly expressed consent (same as its legal basis). Note that this example does not show when the consent was given as well as any other contextual information (e.g. expressed where, how).

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasLegalBasis": "dpv:ExplicitlyExpressedConsent",
    "dpv:hasConsentStatus": {
        "@type": ["dpv:ConsentGiven", "dpv:ExplicitlyExpressedConsent"]
    }
}

Event Time

This field MUST be present.

The time of the associated event (e.g. giving consent, withdrawing consent), indicated using dpv:isIndicatedAtTime. [[ISO-27560]] defines this field as the time the event was expressed or exercised by the specified entity (e.g. when data subject gave consent), and requires this field use a value as per [[ISO 8601]] UTC time to declare the timestamp associated with the event.

To express how the data subject can withdraw consent.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasConsentStatus": {
        "@type": "dpv:ConsentGiven",
        "dpv:isIndicatedAtTime": "2023-11-05T16:08:50"
    }
}

Event Duration

This field MUST be present.

Indicates the duration or the condition for determining validity of the duration for the event. It is indicated using dpv:Duration and associated using dpv:hasDuration. DPV provides the following duration concepts:

TemporalDuration for indicating a relative temporal duration, e.g. 6 months from the indicated event date.
UntilTimeDuration for indicating duration that occurs until the end of specified time, e.g. until 31 DEC 2023.
UntilEventDuration for indicating duration that occurs until the end of specified event, e.g. until account is closed.
FixedOccurencesDuration for a duration that is based on number of occurences, e.g. using it 3 times
EndlessDuration for indicating a duration without an end condition or temporal notation. Note that endless duration is not considered best practice and is considered invalid in several jurisdictions.

[[ISO-27560]] specifies that where the duration relates to the validity of given consent, the duration also indicates that the Data Controller should request the data subject to confirm or 'refresh' their consent without which the consent cannot be valid for processing.

This example specifies the duration for the given consent is 6 months (expressed using [[ISO 8601]] from the indicated time, after which it can no longer be considered valid.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasConsentStatus": {
        "@type": "dpv:ConsentGiven",
        "dpv:isIndicatedAtTime": "2023-11-05T16:18:25",
        "dpv:hasDuration": {
            "@type": "dpv:TemporalDuration",
            "rdf:value": "P6M"
        }
    }
}

This example specifies the duration for the given consent is until the end of the 2023 year, which is independent of the time the consent was expressed.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasConsentStatus": {
        "@type": "dpv:ConsentGiven",
        "dpv:isIndicatedAtTime": "2023-11-05T16:18:25",
        "dpv:hasDuration": {
            "@type": "dpv:UntilTimeDuration",
            "rdf:value": "2023-12-31T23:59:59"
        }
    }
}

This example specifies the duration for the given consent is until the specified event of closing the associated user account.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasConsentStatus": {
        "@type": "dpv:ConsentGiven",
        "dpv:isIndicatedAtTime": "2023-11-05T16:18:25",
        "dpv:hasDuration": {
            "@type": "dpv:UntilEventDuration",
            "rdf:value": "Closure of User Account"
        }
    }
}

This example specifies the duration for the given consent is limited to its use a single time (number of occurences = 1), after which it can no longer be considered valid. This is relevant for contexts such as when data is being collected and the consent is used to perform such collection and processing a single time. The corresponding DPV concept of dpv:SingularFrequency can be used to depict this explicitly.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasConsentStatus": {
        "@type": "dpv:ConsentGiven",
        "dpv:isIndicatedAtTime": "2023-11-05T16:18:25",
        "dpv:hasDuration": {
            "@type": "dpv:FixedOccurencesDuration",
            "rdf:value": "1"
        }
    }
}

Expression by Entity

This field MUST be present.

Indicates which entity or agent (party in [[ISO-27560]]) exercised or expressed the specified event. For example, if it was the data subject or their guardian who expressed the given consent. In DPV, this is indicated using the appropriate dpv:Entity concept and associated using dpv:isIndicatedBy.

In [[ISO-27560]], this field is called entity id and is used to link to the relevant entity through their identifier (e.g. data subject identifier or to an entry in the party section). As this field MUST be present in [[ISO-27560]], the most common value expected here will be a reference to the data subject. In DPV, this can also be indicated using dpv:DataSubject instead of the identifier.

This example specifies that the consent request was expressed by Acme Inc. (as the data controller), while the given consent and its withdrawal were both expressed by the data subject.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasConsentStatus": [{
        "@type": "dpv:ConsentRequested",
        "dpv:isIndicatedBy": "ex:AcmeInc"
    }, {
        "@type": "dpv:ConsentGiven",
        "dpv:isIndicatedBy": "dpv:DataSubject"
    }, {
        "@type": "dpv:ConsentWithdrawn",
        "dpv:isIndicatedBy": "dpv:DataSubject"
    }],
    "dpv:hasEntity": {
        "@type": ["dpv:Organisation", "dpv:DataController"],
        "@id": "ex:AcmeInc"
    }
}

This example specifies that the consent request was implemented by Beta Inc. (as the data processor) operating on behalf of Acme Inc. (as the data controller)

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasConsentStatus": [{
        "@type": "dpv:ConsentRequested",
        "dpv:isIndicatedBy": "ex:AcmeInc",
        "dpv:isImplementedBy": "ex:BetaInc"
    }, {
        "@type": "dpv:ConsentGiven",
        "dpv:isIndicatedBy": "dpv:DataSubject"
    }, {
        "@type": "dpv:ConsentWithdrawn",
        "dpv:isIndicatedBy": "dpv:DataSubject"
    }],
    "dpv:hasEntity": [{
        "@type": ["dpv:Organisation", "dpv:DataController"],
        "@id": "ex:AcmeInc"
    }, {
        "@type": ["dpv:Organisation", "dpv:DataProcessor"],
        "@id": "ex:BetaInc"
    }]
}

This example specifies that the consent concerning the data subject (a child) was expressed by the data subject as well as by their parent. An additional optional annotation is provided using dpv:hasJustification to justify the necessity of parent involvement. Such justifications are useful to indicate relevant context in cases such as where the data subject is not involved or where only the parental or guardian consent is required.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasDataSubject": {
        "@id": "0760c9ba",
        "type": "dpv:Child"
    },
    "dpv:hasConsentStatus": {
        "@type": "dpv:ConsentGiven",
        "dpv:isIndicatedBy": [
            "dpv:DataSubject",
            {
                "@type": "dpv:ParentOfDataSubject",
                "dpv:hasJustification": "The processing also requires parental consent"
            }
        ]
    }
}

Expression Method

This field MAY be present.

Indicates how the specified entity expressed or exercisde the indicated event, e.g. a data subject clicked the button to give consent. This field is not present in [[ISO-27560]], but is considered best practice to document so as to record information relevant to the assessment of consent validity and legal compliance. In DPV, it is associated using dpv:hasIndicationMethod.

This example specifies that the consent given by the data subject was expressed by clicking a button within the presented dialogue.

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasConsentStatus": {
        "@type": "dpv:ConsentGiven",
        "dpv:isIndicatedBy": "dpv:DataSubject",
        "dpv:hasIndicationMethod": "Agree button in dialogue"
    }
}

Examples

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasConsentStatus": {
        "@type": "dpv:ConsentGiven",
        "dpv:isIndicatedBy": "dpv:DataSubject",
        "dpv:hasIndicationMethod": "Agree button in dialogue"
    }
}

{
    "@id": "https://example.com/a6f58318-72e6-46a2-bfd7-f36d795e30cd",
    "@type": "dpv:ConsentRecord",
    "dpv:hasConsentStatus": {
        "@type": "dpv:ConsentGiven",
        "dpv:isIndicatedBy": "dpv:DataSubject",
        "dpv:hasIndicationMethod": "Agree button in dialogue"
    }
}

Lifecycle of Consent

Processing of personal data utilises Consent as one of the possible legal bases. In the current regulatory environment, such consent has to be valid according to several criterion such as being informed, freely given, and being unambiguous. For consent to be informed, the data subject must have been provided or be aware of relevant information regarding the processing of personal data, typically through a Consent Notice, which describes the effect of their decision i.e. if consent is given which processing activities will take place, over which data, and who is involved in terms of entities. Other criterion, such as freely given and being unambiguous is determined through the manner in which this information is presented to request consent and how that consent is expressed.

Once a consent has been given by the individual, they may also have the ability to regulate its use by withdrawing it at a later time. Such termination of consent results in the halting of its associated processing activities. Other causes of termination can be the expiry of duration for which the consent would be considered valid, termination by the Controller, or the consent being declared invalid by an authority such as the court.

Based on these, a lifecycle can be charted regarding the various states that 'consent' can be stated to be in, which is essential to understand which states can be considered 'valid' for the processing of personal data. In the diagram below, consent states begin with a notice being shown to inform the individual and request their consent. Following this, the individual may make the decision to give or grant their consent, or to refuse it. If consent has been given, it can be re-confirmed or re-affirmed to assert its validity, or it can be terminated for several reasons such as its withdrawal by the individual. In all these, only when consent continues to be in a 'given' state can it be used to justify processing.

Therefore, when creating records of consent - such as to demonstrate compliance, it is essential to not only have information regarding the processing activities governed by that consent, but to also have information which relates to determination of it being valid at a given time. This includes how the notice was provided, the type of consent that was expressed, and to associate these with relevant regulatory requirements that dictate the requirements for validity. In addition, changes to consent must also be recorded, whether they relate to an update to information resulting in a new notice, or the confirmation of an existing consent, or the termination of consent for reasons such as being withdrawn.

Consent Records

[[[ISO-27560]]] defines Consent Record as the documentation of information about a data subject's consent for the processing of their personal data in terms of the details about the processing as well as the interactions related to consent (e.g. giving or withdrawing it). Consent Records are an essential part of keeping records regarding whether consent has been obtained and is valid for processing, and to keep this information for correctly conducting processing relying on it. [[ISO-27560]] as well as regulatory requirements such as [[GDPR]] Article 7-1 require maintaining consent records where consent is used as the legal basis. While GDPR Article 7-1 only states that consent should be demonstrable, [[ISO-27560]] provides an information structure for how this information should be maintained and what processes should exist within an organisation in connection with it.

It is important to distinguish between a Consent Record with several relevant but distinct concepts. A consent record only refers to the information recorded regarding consent, whereas a Consent Notice refers to the notice and information provided to the data subject in order to inform them about the processing - such as while requesting consent. While there is a significant overlap between a consent record and a consent notice, there are key differences such as notices orienting information for human consumption (e.g. layering of dialogues to provide summaries and detailed descriptions) and dictating the manner in which consent is expressed (e.g. checkboxes for options and confirmation by clicking a button). In contrast, a consent record is not required to accurately reflect the manner in which this information was presented to the user, but to only record it in a manner that enables assessing whether the consent is given and if so for which processing activities.

This distinction is evident in [[[ISO-29184]]] being the standard for consent notices - which specifies what information should be present in a notice and the manner in which it is presented. In turn, [[ISO-27560]] only refers to notices to limit its scope to representing information necessary within a consent record. Therefore a consent record, despite containing a link to the notice, is not by itself sufficient to determine the validity of consent, and instead acts as the primary record containing information or links to information for conducting such assessments. Its primary purpose is therefore limited to provide an indication of the state of consent (e.g. request, given, terminated) for specific processing activities (e.g. which purpose, what recipients) and to document where additional information can be found on specific matters such as the notice shown when requesting consent.

A [[ISO-27560]] conformant consent record typically has the following sections representing relevant information:

Under GDPR, the obligation to maintain records of consent is explicitly stated in Article 7-1 and Recital 42. This information includes, at a minimum, the identity of the Controller and the purposes of processing (Recital 42). Further Articles 13 and 14 dictate the information that must be provided to the data subject which includes recipients, transfers to third countries, data storage periods and conditions, existence of rights (including consent withdrawal), and specific information regarding processing such as the use of automated decision making or profiling.

Consent Receipts

[[ISO-27560]] defines a consent receipt as an authoritative document that is used to communicate the existence of a consent record or to provide information contained within it. It is effectively an 'authoritative copy' of a consent record provided by one entity to another, where it may contain all, some, or no information from the consent record regarding the consent and its relevance to processing activities. Such receipts may be useful to communicate the existence of consent decisions, or enable entities to exercise of rights or raise issues and complaint regarding processing activities.

Consent receipts are a relatively newer and under-utilised practice, with no legal requirements existing that refer to the concept (or receipts) or state how they should be used. [[ISO-27560]] follows this by leaving it up to the organisations to decide how they want to implement receipts and what information is be provided through it. It defines a minimal structure consisting of some fields representing the receipt metadata, but does not have any requirements on the information within the receipt or its correspondence to fields within the record.

A [[ISO-27560]] conformant consent receipt only requires a metadata section providing information about the consent receipt such as its identifier. Deciding on which additional information is to be provided and in what forms and using which structures is left up to implementing entities. In this guide, we presume that the consent receipt is intended for providing a copy of all information within the consent record.

Namespaces

Introduction

Consent Records and Receipts

Objectives

Scope

Terminology

Overview of Consent in DPV

Overview of 27560

Goals & Scope

Structure

Consent Receipt

Mapping 27560 to DPV and GDPR

DPV-27560 Consent Record

Record Metadata

Schema Version

Record Identifier

Data Subject

Additional Metadata

Notice Fields

Notice

Notice Language

Processing Fields

Personal Data Handling

Purpose

Personal Data

Personal Data Type

Personal Data Identifier

Personal Data Necessity

Sensitive and Special Category

Processing Operations

Data Source(s)

Storage Condition(s)

Processing Condition(s)

Geographic Restriction(s)

Data Controller(s)

Legal Basis

Recipients

Consent Change & Withdrawal

Jurisdiction(s)

Rights

Service(s)

Code of conduct(s)

Impact assessment(s)

Entity Fields

Name

Identifier

Role

Contact

Postal Address

Email

Phone

URL

Consent Event Fields

Consent Type

Consent State

Event Time

Event Duration

Expression by Entity

Expression Method

Examples

DPV-27560 Consent Receipts

Header Fields

Schema Version

Record Identifier

Associated Consent Record

Creation Timestamp

Additional Metadata

Information in Receipt

Examples

Extending with Profiles

Considerations

Security and Privacy

Information Modelling

Recording Privacy Signals

Additional Schemas and Profiles

Lifecycle of Consent

Consent Records

Consent Receipts