§ Data Agreement (DA) Specification

Specification Status: version 2.1.0 (Released and implemented)

Latest version: Avaialble here

Editors:

• Mr. Jan Linquist (Linaltec, Sweden)
• Ms. Lotta Lundin (iGrant.io, Sweden)
• Mr. Lal Chandran (iGrant.io, Sweden)

Contributors and Reviwers:

• Mr. George Padayatti (iGrant.io, Sweden)
• Dr. David Goodman (iGrant.io, Sweden)
• Mr. Pekka Lampelto (PrivacyAnt, Finland)

Participate:

• GitHub repo
• File a bug

§ Abstract

A Data Agreement records the conditions for an organization to process personal data in accordance with privacy regulation (e.g. GDPR) captured in a signed receipt given to the individual. To automate creation of the record and increase the trust assurance a Data Protection Impact Assessment may be used to populate the record.

§ Introduction

This specification describes how a Data Agreement between an organisation and individual is managed in order to capture, in a receipt, the conditions of processing of personal data. The receipt acts as evidence and demonstrates a higher level of accountability and is based on standard schemas. The accountability is further enhanced by directly integrating the Data Agreement with the input from a risk assessment, e.g. Data Protection Impact Assessment.

In order to create the Data Agreement, and the resulting receipt as proof, a number of steps are required from different actors. This document describes these steps involved and is described as part of a Data Agreement lifecycle.

§ Abbreviations

§ Data Agreement lifecycle actors

These actors are involved in the Data Agreement lifecycle.

• a Data Source, the organisation collecting private data, (typically a data controller). [SSI: Issuer]
• a Data Subject or Individual. [SSI: Holder]
• a Data Using Service (DUS), an organisation processing personal data from one or more data sources to deliver a service. [SSI: Verifier]
• an Assessor reviews the practices of an organisation**, **conducts a DPIA and drafts data agreements and inter-company agreements for third parties.
• an Auditor may be called in to review the data agreements and ensure they are in place in case of data breaches or regular inspection.

In addition to these actors to better understand the interworking, these nodes are relevant.

• Assessment Platform or DPIA Tool is used by Assessor to create reports and populate Data Agreements.
• ADA Service represents the microservices that can be plugged into any service provider wishing to adopt ADA services.

§ Data exchange agreements landscape

This chapter introduces various agreements and relationships that exist between organisations and individuals, depending on their roles in the personal data usage scenarios in a personal data economy. The various agreements involved can be classified into two broad categories:.

1. Agreement between an individual and an organisation
2. Agreement between two organisations

This specification focuses on agreement between an individual and an organisation; the agreement between two organisations is not within the scope of this specification and is mentioned here for the sake of completion.

§ Agreement between an individual and an organisation

This is an agreement between organisations and individuals in the use of personal data. We refer to this as the “Data Agreement” which can have any of the legal basis that is outlined as per data protection law or regulation, such as the GDPR. The agreement with individuals could be with a Data Source (issuer) or a Data Using Service.

The focus of this specification is on the Data Agreement, how it is defined, prepared by an organisation wishing to use personal data, how it is negotiated with an individual and finally how an auditor is able to audit the data agreement involved in a data transaction.

§ Agreement between two organisations

There can be two forms of agreements between two organisations.

The first form of agreement is between organisations where one organisation acts as a Data Source and the other as Data Using Service. In this case, both organisations share the role as data controller and are responsible for managing their compliance requirements. They may have made their own privacy risk assessment, documented in a data protection impact assessment (DPIA) report, and concluded whether any additional mitigation effort was required. This agreement is referred to as Data Disclosure Agreement, which, though not yet standardised, captures the agreement between two organisations on how data is shared and what obligation each party has. This can be realised as a contract or in terms of use. The individual (data subject) is engaged with both organisations. For each organisation, there exists a Data Agreement with an associated privacy policy that explains the purpose of processing personal data, what personal data is collected, data subject rights, etc.

The second form of an agreement in this category is between an organisation and their suppliers as illustrated below.

Here, there is a vertical relationship between an organisation A as a data controller and their suppliers as data processors or sub-processors. For a higher level of accountability between these organisations, a Data Processing Agreement is set up, which lays out what routines are required to be in place: for example, data processor’s obligations in case of data breaches or how rights of the data subject, such as access rights, are supported, among other policies and routines. An auditor should also be able to inspect an organisation, and use the data processing agreement as reference during the inspection.

As depicted in the diagram above, the data agreement with the individual is bound to the top of the hierarchy, i.e. the data controller or organisation.

§ Data Protection Impact Assessment (DPIA)

A Data Protection Impact Assessment (DPIA) is a structured process where an organisation can identify and minimise the data protection risks involved in the use of personal data. It ensures that an organisation is compliant to data regulations, such as the GDPR.

Article 35 of the GDPR requires organisations to conduct DPIAs, especially when the processing is likely to result in high risk to the rights and freedoms of natural persons in the case of extensive use of new technologies and when sensitive personal data is being processed (e.g. health-related data). Organisations can also conduct DPIAs voluntarily, even if the processing does not meet the requirement criteria set out in the GDPR.

Some EU Member State data protection authorities, such as the Finnish data protection ombudsman, have recommended using dataflow maps when conducting DPIAs. Dataflow maps visualize the flows of personal data across systems, organisations, and jurisdictions, and provide a good overview of the nature and scope of the processing and identify risks.

Appendix B outlines how a DPIA report can map to a Data Agreement. By integrating the DPIA into the lifecycle of the Data Agreement an organisation can demonstrate how the privacy requirements of accountability, transparency, data sharing and retention procedures are fulfilled. If the DPIA report is part of an online tool it is possible to continuously monitor an organisation’s data flows and ensure any internal changes are reflected in the Data Agreement.

§ Data Agreement functional overview

This section provides a functional overview of the Data Agreement and is broken down into:

• Data Agreement lifecycle
• Applicable use cases
• Overview of how the actors interwork

§ Data Agreement Lifecycle

The Data Agreement Lifecycle has 4 main phases as described below:

1. Definition: In this phase, an authority adapts the data agreement schema to a particular industry and/or sector specific data usage as a template. This can then be used by any organisation (Data source or Data Using Service) for a particular data usage purpose.
2. Preparation: In this phase, an organisation uses an existing data usage template and prepares it to be published towards the individuals. This could be based on a DPIA and could be for internal use of data or for data exchange to a Data Using Service. Once the Data Agreement is prepared,any changes identified from a subsequent DPIA shall update the Data Agreement and go through a new preparation process. When an agreement is updated or terminated, the individuals are notified and a record is created.
3. Negotiation/Capture: In this phase, an individual reviews the Data Agreement and, once agreed, it is captured in a Data Agreement record by the organisation and the individual is given a Data Agreement receipt as evidence of the agreement. The Data Agreement receipt can be used as proof for the data transaction that occurred. This allows an auditor to check and ensure records are in place to process the individual’s personal data. When the agreement is terminated and is no longer applicable towards an individual, a new record is created. The termination can be due to the service period being completed or an individual requests to revoke the agreement. The record of the termination allows an auditor to inspect personal data that is not used. If an individual requests to be forgotten when terminating a service it shall be clearly indicated.
4. Proof: An organisation is able to demonstrate a valid Data Agreement record for performing a data exchange with an individual. This allows an auditor to check and ensure records are in place to process the individual’s personal data.

How each actor is involved in the different phases can be found in this table.

§ Use Cases

These are the use cases covered by this specification. A mapping between the use cases and lifecycle phase can help map to the involved actors described in the previous section.

§ Sequence diagrams

§ Definition and Preparation phases

“Definition” and “Preparation” phases of the Data Agreements lifecycle have the following functions which can be seen in the sequence diagram.

1. Populate the Data Agreement. This could be based on a DPIA or a self evaluation. This calls the CRUD (Create/Read/Update/Delete) operations on the Data Agreement(s).

2. Publish/unpublish Data Agreement(s) towards deployments by ADA Service. When it is published, it’s available towards the individual.

§ Negotiation/Capture phase

In this phase, an Individual can Sign and Revoke (Opt-out) a data agreement which results in a data agreement receipt. The signing can be performed using a unique identifier during the creation of a verifiable credential or when performing proof presentation for example when showing proof of identity. Typically the proof may be expected to be the first step to connect with an organization.

§ Issuing credentials (Data Source)

The below sequence diagram shows how the steps of issuing a credential can be used to present and agree on the Data Agreement. The Data Agreement will be presented as an offer and once accepted a receipt is created. The sequence of actions are:

1. A Data Source offers to issue data and adds a reference to a signed Data Agreement.
2. Once the user agrees to the data offer and accepts it, the agreement is counter signed and a receipt is created.

The following diagram is from Aries 0036 Issue Credential and the text in red represents how a Data Agreement is processed as part of a credentia offer when it is accepted or rejected.

§ Verifying credential (Data Using Service)

The below sequence diagram shows the Data Agreement flows for a verifier or Data Using Service, when requesting data to be shared by the individual. The sequence of actions are:

1. A Data Using Service makes a request for proof and adds a reference to a signed Data Agreement.
2. Once the user agrees to the data offer and accepts it, the agreement is counter signed and a receipt is created.

The following diagram is taken from Aries 0037 Presentation Proof and the text in red represents how the Data Agreement is processed in the offer and accepted with the option to reject.

§ Termination

The Data Agreement may be terminated in a number of ways. Here are a few of the scenarios:

1. Data Agreement expired and the service is no longer applicable
2. Updated Data Agreement with new purpose or changes to collected pii categories
3. Individual requests to terminate the service before expiration date
4. Individual requests not only terminate but have their personal data erased

Note the erasure may come after termination of the Data Agreement.

The following diagram is the case for individual requests to terminate scenario 3, individual requests termination.

§ Proof

In accordance with GDPR Art. 30, Records of processing activities, a Data Controller (Data Source and DUS) shall record processing activities under its responsibilities. The records shall be available to the individual to inspect in the form of a receipt and provide means of an audit. An audit can be initiated due to the following reasons:

1. Complaint by Data Subject (Or Individual)
2. Review of Data Source or Data Using Service record logs

The complaint by Data Subject (Or Individual) will include a copy of the Data Agreement receipt and explanation of the violation by Data Source or DUS.

The following sequence is the approach taken when the auditor reviews implementation of Data Agreement capture and withdrawal. If the auditor lacks the software to perform the read then a dashboard access is provided by the Data Source or DUS. In case of a Data Subject complaint, a reference to the original Data Agreement is shared with the Auditor so the Auditor can perform the same verification.

§ References

[1] Data Agreement Interface Specification

[2] Data Agreement - DID Method Specification

[3] Kantara Consent Receipt Specification

[4] ISO/IEC 29184: 2020: Information Technology - Online Privacy Notices and Consent (Published, available at https://www.iso.org/standard/70331.html)

[5] ISO/IEC TS 27560 — Privacy technologies — Consent record information structure (Not published yet)

§ Appendix A: Data Agreement schema

This section describes the content of the Data Agreement. The schema is based on Kantara Consent Notice [3], as well as ongoing ISO standardization under ISO project 27560, Consent record information structure. Note ISO/IEC TS 27560 [5] is not yet published as it is only referred to by field names but the input requirements for 27560 is the published ISO standards 29184, Information technology - Online privacy notice and consent [4].

Table below captures, at a high level, the various attributes to be collected when recording and creating Data Agreement receipts. This is based on analysis of the DPIA reporting and the various standards analysed.

NOTE: For deeper analysis of the DPIA mapping exercise refer to this link.

The following table lists the required fields in the Data Agreement. The attribute names are from ISO 27560 and for better insight the Kantara 1.1 fields are included.

§ Appendix B: DPIA (Risk Assessment)

This appendix describes how a DPIA reports maps to the Data Agreement. For deeper analysis of the DPIA mapping exercise refer to this link. DPIA reports are typically composed of the following sections:

1. Overview
2. Scope
3. Roles and responsibilities
4. Processing Overview
5. Scope of Processing
6. Context of Processing
7. Stakeholder Engagement (Data Subject)
8. Compliance with data protection law and other regulatory guidance
9. Identify and Assess Risks
10. Identify measures to Reduce Risks
11. Sign off and Record Outcomes

The key areas for input to the Data Agreement are Roles and Responsibilities, Scope of Processing and Context of Processing. The Context of Processing establishes the lawful basis for processing personal data. The Roles and Responsibilities lists all involved entities like data controllers, data processors and sub-processors.

The Scope of Processing section looks into private data processing in more detail. Typically this sections covers the following:

1. Data Subject Categories
2. Data Types
3. Data Collected/Processed
4. Data Retention
5. Parties Access/Use (member/role/access)
6. Personal Data (attribute level, type, collection activity, frequency)

§ Data Agreement mapping from DPIA

The following table provides a mapping between the DPIA report and the Data Agreement.

§

§ Appendix C: Standards Input

This section serves as a reference to some of the material that has been used for the development of the Data Agreement schema.

§ Kantara Schema Reference

Kantara Consent Receipt Specification v1.1.0

§ ISO Standards

The two ISO standards relevant to Data Agreements are as below.

1. ISO/IEC 29184: 2020: Information Technology - Online Privacy Notices and Consent

2. ISO/IEC TS 27560 — Privacy technologies — Consent record information structure