# Ask for consent

Consent allows users to control how their personal data is accessed, used, stored, or shared within a service. 

You do not need to ask for consent when:

* data processing is required by law for a government task or statutory function
* processing is necessary to deliver a service under authority or contract
* individuals cannot reasonably be identified from the data

In these cases, clearly inform users instead of requesting consent.

## Steps

{% @mermaid/diagram content="---
config:
theme: redux
layout: dagre
-------------

flowchart LR
A\["Find the service<br>"] --> B\["Before you start<br>"]
B --> C\["Consent: access personal details to check eligibility<br>"]
C --> D\["Consent given?"]
D -- No --> X\["Stop or route user appropriately"]
X --> Z\["End / cannot proceed"]
D -- Yes --> E\["Check eligibility<br>"]
E --> F\["Check answers<br>"]
F --> G\["Question pages<br>"]
G --> H\["New purpose introduced?"]
H -- No --> P\["Service proceeds<br>Use existing consents only<br>"]
P --> Q\["Outcome / continue service"]
H -- Yes --> I\["Present consent request for the new purpose<br>"]
I --> J\["Consent given?"]
J -- No --> K\["Handle partial consent<br>"]
K --> H
J -- Yes --> L\["Record auditable consent decision<br>"]
L --> H
I -. Example: verify qualifications .-> I1\["Consent: verify qualifications with education provider"]
I -. Example: criminal history check .-> I2\["Consent: run criminal history check"]
I -. Example: share decision .-> I3\["Consent: share licence decision with regulator"]

A@{ shape: rounded}
B@{ shape: rounded}
C@{ shape: rounded}
D@{ shape: diam}
X@{ shape: rounded}
Z@{ shape: rounded}
E@{ shape: rounded}
F@{ shape: rounded}
G@{ shape: rounded}
H@{ shape: diam}
P@{ shape: rounded}
Q@{ shape: rounded}
I@{ shape: rounded}
J@{ shape: diam}
K@{ shape: rounded}
L@{ shape: rounded}
I1@{ shape: rounded}
I2@{ shape: rounded}
I3@{ shape: rounded}
" %}

<details>

<summary><strong>Example user flow</strong></summary>

<figure><img src="https://content.gitbook.com/content/u8moxPbFWK9pTxPYNIyh/blobs/2FN37JNKNdkKOT01zPWY/Ask%20for%20consent.png" alt=""><figcaption></figcaption></figure>

</details>

Consent may be requested at the start of the journey or at specific points where a new purpose is introduced and user approval is required to proceed.

#### 1. Understand why consent is needed

Users' consent should be requested for a specific purpose. If you use the data for more than one reason, get separate consent for each.&#x20;

Ask for users consent when you need to:

* access a user’s personal data including from another authority or provider
* store, manage, or retain personal data
* share personal data with another system or organisation
* allow users to view, manage, or withdraw previously given consent

Users need to understand:

* what data will be accessed or shared
* why it is needed
* who will receive it
* how long it will be used or stored

#### 2. Decision to give or refuse consent

Give users a clear choice to accept or refuse consent without being misled, coerced or pressured.&#x20;

Where multiple datasets or purposes are involved, users can:

* give consent for all
* Give consent for some and refuse others

Use the [ask questions pattern](https://docs.google.com/document/d/15us8IahaUh_aTsT1_XQhCMqQLO_PakzTrqC9IUO-x2k/edit?tab=t.dkz2pzax2bvr) with appropriate questions fields such as checkbox or radio button to suit the purpose.&#x20;

Outcomes for consent decisions include:&#x20;

* Partial consent that must be respected.
* Accepting consent that allows the service to proceed for that purpose.
* Refusing consent that stops the related processing. The service must explain what will happen if consent is refused.

Use [outcome pattern](https://docs.google.com/document/d/15us8IahaUh_aTsT1_XQhCMqQLO_PakzTrqC9IUO-x2k/edit?tab=t.ic66r6ozbbk6) where partial or no consent is given to communicate what happens next. &#x20;

Inclusive design considerations:

* If users may need time to understand what they are agreeing to, the journey should enable save and return.&#x20;

#### 3. Proceed to service using the given consent

Before accessing or sharing data, the service checks that valid consent exists. The service uses consent only for the agreed purpose.\
Consent is recorded with purpose, scope, and timestamp.

#### 4. Amend or revoke consent

Users can review, change, or withdraw consent after it has been given. Withdrawing consent stops any future processing for that purpose. The service explains the impact of changing consent.

Consent management may happen within the service or through a dedicated consent management interface.

***

## Considerations

#### Technical considerations

Consent rules must be explicit and purpose-based.

Each consent decision should be:

* linked to a specific purpose
* associated with the data involved
* time-bound where applicable
* recorded with date, version, and context

Systems must be able to:

* check whether valid consent exists before accessing data
* prevent processing when consent is refused or withdrawn
* support auditing and compliance reviews

Integrations should rely on authoritative data sources and trusted consent records, in line with the Consent Building Block.

<br>