4 Key Digital Functionalities
Key Digital Functionalities describe the core (required) functions that this Building Block must be able to perform.
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.
Consent use-cases | Link(s) to the UCS |
CREATE CONSENT AGREEMENT - Here, an organisation Administrator creates a Consent Agreement based on the Data Policy requirements. | |
UPDATE CONSENT AGREEMENT - Here, an organisation Administrator updates the Consent Agreement based on the Data Policy requirements. | |
READ CONSENT AGREEMENT - Here, an organisation Administrator reads the Consent Agreement. | |
DELETE CONSENT AGREEMENT - a special case of consent agreement update. | |
CONSENT AGREEMENT CHANGE NOTIFICATION - Notifications for Data Providing and Data Consuming Systems, as well as Individuals upon changes to Agreement or Policy configuration. |
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.
Consent use-cases | Link to the UCS |
VIEW CONSENT - Here, the Individual views the Consent Agreement and the conditions for Personal Data processing (with adequate clarity for informed understanding). This includes obtaining copies of the consent agreement. | |
GIVE CONSENT - Here, the Individual signs a Consent Agreement during a data sharing workflow. Note that this can also happen offline without data sharing in place. | |
WITHDRAW CONSENT - Or update existing consent | |
Consent agreement change notification |
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).
Consent use-cases | Link to the UCS |
AUDIT CONSENT - Query the Consents related to individuals or policies (opt-in/opt-opt) | |
MONITOR POLICY UPDATE- Tracking Data Policy changes and configuration conformance with it; | |
READ CONSENT STATUS - Viewing (reading, exporting) the Consent Agreements and relevant reports in a verifiable form | |
VERIFY CONSENT INTEGRITY - Ability to check the integrity of the signed agreements |
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.
Scenario | Source Building Block | Target Building Blocks | Description |
1.1 Querying: Which Consent Agreement is needed for specified data processing/ consumption? | Any | Workflow Building Block | Consent Building Block does have knowledge or state to resolve which Data Consumer or Data Producer requires consent. Everything regarding consent has a precondition that a decision is made and manifested in the Workflow Building Block or any other Data Consumer. |
1.2 Data processing/ consuming system stores/fetches data with consent + prompts the user if none exists | Any | Consent Building Block | Given an Agreement ID and a User ID, the Consent Building Block can resolve if consent exists and possibly prompt the user. Workflow Building Block is especially inappropriate here because of User Interface integration and a blocking and sequential call stack. |
1.3 Data processing/ consuming system stores/ fetches data with consent, no halts operations without consent | Any | Workflow | Given an Agreement ID and a User ID, the Workflow Building Block can complete an atomic action requiring consent. Operations shall not proceed if consent does not exist. |
1.4 Data processing/ consuming system stores/ fetches data with consent, consent is prompted asynchronously | Any | Workflow | The Workflow Building Block may halt operations and asynchronously prompt the user for consent if none exists (or is invalid). After fetching consent, the Workflow Building Block should revert to the targeted data consuming/ processing operation. |
1.5 Appropriate access to data that does not require consent | Any | Workflow | Not necessarily related to Consent Building Block. |
1.2-1.4 Side effects | Workflow | Any attempt to read consent and process/consume data is logged and auditable. | |
2.1 Inappropriate access: Data processing/consuming system inappropriately stores/fetches data without consent | Any | N/a | Any consent-requiring data access is assumed logged. Auditing of inappropriate data access is only possible when a log trace exists. |
3.1 | Workflow | Consent | Given an Individual, query if active Consent Records exist (for instance, to spot if other external data needs to be kept). |
4.1 | Any | Consent | Fundamental individual rights (General Data Protection Regulation/ Data Protection Act/ Right to be Forgotten/etc.) |
4.2 | Any | Consent | Fundamental individual rights (General Data Protection Regulation/Data Protection Act/etc.) |
Last updated