4 Key Digital Functionalities

The Consent Building Block enables organisations to enforce Data Policies that require signed consent by Individuals for the use of their Personal Data. Its key purpose is to allow individuals to view Consent Agreements and sign or withdraw their consent on what Personal Data is used and accessible to organisations. It also clarifies the Data Policy applied, such as the purpose, retention period, jurisdiction, third-party data sharing, etc.

The Consent Building Block implements the key functionalities described in the consent management lifecycle. It includes the ability to configure consent agreements by an organisation admin, present consent requests towards individuals, capture consents, enable queries if consent exists, or not, and enable independent audit of consents.

The functionalities are derived from the consent agreement lifecycle and categorised according to the Actors described above. While the consenting workflows (as described above) are implicitly considered the centrepiece of the Consent Building Block, it is important to realise that the integrity of consent management can only be achieved if robust configuration before and auditing after the Consent Agreement signing and Consent Record verification activities are in place. Hence, the functionalities are described following the logical sequence of the consent agreement lifecycle and they are all equally important components of the Consent Building Block.

The Consent process (creating and signing Consent Agreements and Consent Records) is initially managed in the application provided by the Organisation that is legally required to collect the consent. Since it can be either a Data Consuming organisation or a Data Providing organisation, the Consent Building Block allows both to be able to verify their conformance with the underlying Data Policy, both organisations must be able to access and use the application.

While the Actors generally fall in line with the categories of the functionalities, it is important to realise that “auditing” functions in the narrow sense, verifying if data processing is being (or has been) processed according to the Data Policy requiring a consent, is relevant to various entities involved in the data processing. For this reason, the generic “verification” activity may be executed as part of various workflows satisfying the needs of different actors.

Following is the first core set of key functionalities of the Consent Building Block. For potential future developments of the specification follow the work in progress at GovStack confluence page.

4.1 Administrator User Functionalities

The Administrator (Data Provider or Data Consumer Admin) configures the Consent Building Block on behalf of the organisation. For simplicity, it is foreseen that one organisation involved in the data processing transaction (that is either Data Provider or Data Consumer) takes the responsibility for the configuration of the Data Policy and respective Consent Agreements(s), and so that the organisation’s Administrator maintains the required configurations.

The main Administrator actions expected to perform via Consent Building Block are:

• configuring Data Policies, requesting and signing Consent Agreements with Individuals;

• viewing (reading, exporting) the Consent Agreements and relevant reports;

• event-driven (opt-in or opt-out) subscription to (notifications of) changes in Consent Agreements;

• logging and maintaining an auditable overview of all Personal Data transactions according to Consent Agreements as well as configuration versions.

The table below summarises the key use cases identified for an organisation's Administrator. Organisations can be Data Consumers or Data Providers, i.e. the organisations legally delegated the responsibility for collecting consent for the systems handling Personal Data processing.

4.2 Individual User Functionalities

The capabilities for individuals that Consent Building Block supports are:

• viewing and understanding Data Policies applying to their Personal Data processing;

• agreeing and disagreeing with and toggling between the conditions of Personal Data use as described in the Consent Agreement;

• obtaining copies of their Consent Agreement(s);

• delegating their consent rights (out-of-scope for current technical release).

The scope for the current version of Consent Building Block assumes that the Individual is acting for themselves. Ultimately the Consent Building Block will include in the Consenting Process the capacity to sign a Consent Agreement in the name of another individual - to act as the Delegate, which is used as the criterion for technical implementation. However, the Delegate and the Individual relationship is expected to be maintained outside of the Consent Manager, which assumes that the person signing the Consent Agreement (i.e. Consenter) has been authorised to do so.

The table below summarises the key use cases identified for the Individuals.

4.3 Data Processing Auditor User Functionalities

Important note: In the Consent Building Block, we define the Data Processing Auditor's role (see 1.3 Terminology and 1.5.3 Actor definition) as an organisation's auditor implementing the Consent Building Block. The auditor role will most probably be akin to a Data Protection Officer (DPO), possibly from an external third-party organisation and involve activities outside of the Consent Building Block.

To avoid ambiguity, we use the precise term Data Processing Auditor to stress the specificity of tasks to be performed by and for the Consent Building Block; all other actions not within the Consent Building Block's scope are considered as an external prerequisite and as a “black box” activity. With respect to audit, this role is distinguished from the data policy auditor. The Data Processing Auditor relies on an audit universe defined by the control and risk management of the specific project and context (i.e. outside the Consent Building Block). “Who needs to consent to what” is the outcome of a DPIA (Data Protection Impact Analysis), ensuring that the data policies are compliant with the relevant data protection regulations for the project.

The main actions a Data Processing Auditor (or Data Protection Officer, DPO) is expected to perform via Consent Building Block are:

• auditing tracking the consents (opt-in/opt-out);

• auditing tracking Data Policy changes and configuration conformance with it;

• viewing (reading, exporting) the Consent Agreements and relevant reports in a verifiable form.

For the implementation of a specific use case, it is important to distinguish the Data Processing Auditor, an actor described here, from a data policy auditor, an actor of the risk organisation. It is expected that the two roles are coordinated in the risk management process. Within the Consent Building Block, the Data Processing Auditor performs the tasks that will allow a data policy auditor to confirm that the implemented system complies with existing regulations demanding consent.The table below summarises the key use cases identified for the Data Processing Auditor.

Also to consider: “READ CONSENT STATUS” use-case is also used by any workflow (and Actor) that requires verification of the consent status (for example, before executing the data transfer from Data Providing System to the Data Consuming System).

Scenarios: Consent and Data Access

As described above under Universal Consenting Workflows, there may be an unlimited number of business processes that require consent. The following scenarios are but a few examples illuminating how appropriate access to data can and should be handled when processing or consuming data with the support of Consent Building Block functionalities.