Annex C: Lawful basis for processing
The guidance in this annex is not linked to a specific standard in the code, but if you provide an online service to children it will help you comply with your lawfulness obligations under the GDPR and DPA 2018.
- What is a lawful basis for processing?
- Which lawful basis can we use for our ‘core’ processing?
- Which lawful basis can we use for ‘non-core’ processing?
- When do we have to get parental consent?
- What about special category data?
What is a lawful basis for processing?
You must have a valid lawful basis for each of your processing activities. Article 6 of the GDPR sets out six potential lawful bases:
(a) Consent: the individual has given valid consent for you to process their personal data for a specific purpose.
(b) Contract: the processing is necessary to perform a contract you have with the individual, or because they have asked you to take specific steps before entering into a contract.
(c) Legal obligation: the processing is necessary for you to comply with the law (not including contractual obligations).
(d) Vital interests: the processing is necessary to protect someone’s life.
(e) Public task: the processing is necessary for you to perform a task in the public interest or for your official functions, and the task or function has a clear basis in law.
(f) Legitimate interests: the processing is necessary for your legitimate interests or the legitimate interests of a third party, unless there is a good reason to protect the individual’s personal data which overrides those legitimate interests – in particular where they are a child. (This cannot apply if you are a public authority performing your official tasks.)
It is up to you to decide which lawful basis for processing is most appropriate to your processing, and demonstrate that it applies. This depends on your specific purposes and on the context of the processing. In practice it is likely that you will have more than one purpose, in which case you may have more than one basis for processing.
You should consider this separately for each distinct processing activity, thinking about what you want to do with the personal data you are collecting and why, and taking into account how essential this is to the provision of your online service.
Further reading outside this code:
Which lawful basis can we use for our ‘core’ processing?
By ‘core processing’, we mean processing which is integral to the provision of your core service – in other words, you need to process the data in that way in order to actually deliver the elements of the service the individual has signed up for. This doesn’t include processing for broader business purposes (eg for marketing, service improvement or as part of an indirect funding model).
For this type of core processing, you could consider:
- (b) Contract: the most obvious basis is ‘necessary for performance of a contract’. However, if you want to rely on this basis, you need to be sure that the child has the legal capacity to enter into a contract. If the child is not competent to enter into the contract then the contract is voidable. If the contract is voided then this basis for processing will not be valid.
- (f) Legitimate interests: alternatively you can consider legitimate interests (unless you are a public authority performing your functions). If you do choose to rely on legitimate interests, you have a particular responsibility to protect children from risks that they may not fully appreciate and from consequences that they may not envisage. You must ensure their interests are adequately protected and that there are appropriate safeguards. You need to give extra weight to their interests, and you need a more compelling interest to justify any potential impact on children. Your DPIA is a useful tool to help you assess this balance.
- (e) Public task: if you are offering a service as part of your public functions, or performing a specific task in the public interest. You need to identify a statutory or common law basis for that function or task.
Consent is unlikely to be the most appropriate basis for processing which is necessary to deliver the core service. This is because the processing is a condition of the contract, so asking for separate consent is unnecessary and potentially confusing. It risks diluting the general concept of consent as a clear and separate choice with no strings attached, and may contribute to ‘consent fatigue’. You only need consent where specifically required under another provision, such as:
- to comply with PECR rules - although you don’t need consent for cookies which are strictly necessary for your service; or
- to get explicit consent for specific elements of your service that process special category data (more on this below).
Legal obligation may be relevant for some fraud prevention, child protection or safeguarding measures, if you can point to a specific legal provision or appropriate source of advice or guidance on your legal obligations.
Vital interests is unlikely to be relevant in this context. Legitimate interests is likely to be a more reliable basis for any measures you take to protect a child’s health or safety.
Which lawful basis can we use for ‘non-core’ processing?
By ‘non-core’ processing, we mean processing that is not integral to the provision of your core service. This includes processing for optional elements of the service, or processing for broader business purposes such as marketing, service improvement or indirect funding models.
You should give the child (and their parent where appropriate) as much choice as you can over these elements of your processing. This includes as a minimum implementing the standards in this code on default privacy settings, data minimisation, geolocation and profiling.
For optional elements of your service which a child has specifically activated, you can consider necessary for contract for any processing which is objectively necessary to deliver that specific element of the service if the child has capacity to enter into a contract, in the same way as for core processing. You can also consider legitimate interests. However, for these to apply, you must give the child separate choices to activate each separate element of the service wherever this is functionally possible. You cannot bundle independent elements of a service together. See also the standard on data minimisation in this code.
You do not need consent under PECR cookie rules as long as the processing is strictly necessary for these extra elements of a service, and they have been requested by the child. There are advantages to using legitimate interests or contract instead of consent, to avoid repeated consent requests and ‘consent fatigue’. However, you still need to conform to the standards in this code related to privacy settings and controls, even if this falls short of a full consent mechanism.
To reinforce the importance of a child’s choice, or as a safeguard against a particular risk to a child’s interests, you may decide to rely on consent for some non-core processing. If you do so then you need to ensure you use a positive opt-in method of consent which is clear, separate from your terms and conditions, separate from your privacy information, and easy to withdraw. You must also comply with Article 8 of the GDPR (as adapted by section 9 of the DPA 2018) and obtain parental consent for children under 13. More on this below. You must also still conform to all the standards in this code to the extent they are relevant to your service.
You should remember that you need GDPR-compliant consent under PECR for any relevant cookies, apps or other technologies which gain access to, or store data on, the user device, but which are not strictly necessary for the service. You should also note the opinion of the European Data Protection Board (EDPB) about processing for the purposes of online behavioural advertising. EDPB has been clear that it considers that legitimate interests will not be an appropriate lawful basis for processing for this type of online activity (which leaves consent as the only remaining viable lawful basis for processing).
If you’re processing for broader business purposes and you are not caught by the cookie rules, you may still be able to consider legitimate interests, public task or legal obligation, depending on why and how you are using the data.
Further reading outside this code:
See our separate guidance on:
- Consent
- Contract
- Legal obligation
- Public task
- Legitimate interests
- Guide to PECR – Cookies and similar technologies
Further reading - European Data Protection Board
The European Data Protection Board (EDPB), which has replaced the Article 29 Working Party (WP29), includes representatives from the data protection authorities of each EU member state. It adopts guidelines for complying with the requirements of the GDPR.
The EDPB has published ‘Opinion 5/2019 on the interplay between the ePrivacy Directive and the GDPR’. This provides useful information about how the cookie rules relate to the GDPR and re-states the positions previously taken by WP29 about when consent should be required for certain processing operations beyond the setting of cookies.
WP29 previously published 'Opinion 3/2013 on purpose limitation’ and 'Opinion 6/2014 on the notion of legitimate interests’. Although this guidance was produced under the previous data protection framework, much of it applies under the GDPR.
When do we have to get parental consent?
Article 8(1) of the GDPR (as modified by section 9 of the DPA 2018) says that if you are relying on consent as your lawful basis:
“in relation to the offer of information society services directly to a child, the processing of the personal data of a child shall be lawful where the child is at least [13] years old. Where the child is below the age of [13] years, such processing shall be lawful only if and to the extent that consent is given or authorised by the holder of parental responsibility over the child.
This does not mean that you always have to obtain parental consent for users under 13. It only applies if you make your service available to children, and you rely on consent as your lawful basis (eg for any non-core processing, cookies or similar technologies, or processing of special category data).
If so, it says you need to make ‘reasonable efforts’ to obtain and verify parental consent for children under 13.
You can take available technology into account in deciding what is reasonable for the purposes of Article 8. You can also consider other circumstances, including your resources and the level of risk identified in your DPIA, but you must be able to justify your approach.
Meeting the standards in this code should also help. This is because the standards in the code work together to mitigate risks arising from the processing of children’s personal data. In particular, if you conform to the standard on age appropriate application (and apply the standards to all users where you are unable to establish age with a level of confidence that is appropriate to the risks) then you are providing significant protections for children by default, even if they have lied about their age. This means that the risks that might arise from not knowing how old a user is, or from not verifying parental consent to a high standard, are reduced. Parental consent becomes only one of a number of measures in place to protect children online.
Your approach to age verification and parental consent under Article 8 should therefore be compatible with your approach to age appropriate application under this code.
If you verify age and parental authority for Article 8 purposes then you need to do so in a privacy-friendly way. Collect the minimum amount of ‘hard identifiers’ (such as passport scans or credit card details). Remember that you need to comply with the GDPR in your processing of any personal data you collect for verification purposes, including the purpose limitation, data minimisation, storage limitation and security principles.
If you are using a third party verification service, you should use ‘attribute’ systems which offer a yes/no response when asked if an individual is over a given age, or if a person holds parental responsibility over the child.
If you can show that your processing is particularly low-impact and does not carry any significant risk to children, you may be able to show that self- declaration mechanisms are reasonable on their own (eg analytics cookies).
If the risks are higher then you need to either rely on more robust methods, or mitigate risks by applying the standards in this code to all users regardless of their self-declared age.
Further reading outside this code:
What about special category data?
If your online service processes any special category data of children, you must identify both a lawful basis under Article 6 and an additional condition for processing that data under Article 9. Special category data includes information about:
- race;
- ethnic origin;
- politics
- religion;
- trade union membership;
- genetics;
- biometric identification (eg facial or fingerprint recognition);
- health (including data collected by fitness apps);
- sex life; or
- sexual orientation.
The most relevant Article 9 conditions are likely to be:
- Article 9(2)(a) - explicit consent: If you need to process special category data to provide a service to the individual, explicit consent may be available as your condition for processing that data even if it is a condition of service. However, you must be confident that you can demonstrate that consent is still freely given. In particular, that the processing is objectively necessary to perform a requested element of the service, and not bundled together with other elements of the service or included in your terms for broader business purposes.
- Article 9(2)(d) - not-for-profit bodies: if you are a not-for-profit body and your online service has a political, philosophical, religious or trade union aim. The child must either be a member or someone in regular contact with you for those purposes, and you must not disclose their data outside your organisation without consent. You must also comply with all the safeguards set out in this code, as well as other appropriate safeguards identified in your DPIA.
- Article 9(2)(g) - substantial public interest: you can rely on this condition if you can meet one of 23 specific substantial public interest conditions set out in schedule 1 of the DPA 2018. You also need an ‘appropriate policy document’ which briefly sets out which condition you are relying on, how you comply with the principles, and your retention and deletion policies (this can be taken from step 4 of your DPIA).
In particular, you may be able to consider the specific substantial public interest conditions in schedule 1 of the DPA 2018 for:
- statutory or government purposes (condition 6);
- preventing or detecting unlawful acts (condition 10);
- preventing fraud (condition 14); or
- safeguarding of children (condition 18)
You should review the detail of these conditions carefully. If no other specific condition is available, you must get the valid explicit consent of the child (or their parent, if the child is under 13), otherwise you cannot process special category data.
You must document and justify your condition as part of your DPIA.
Further reading outside this code
- See our separate guidance on special category data
- Detailed guidance on consent