Take a risk-based approach to recognising the age of individual users and ensure you effectively apply the standards in this code to child users. Either establish age with a level of certainty that is appropriate to the risks to the rights and freedoms of children that arise from your data processing, or apply the standards in this code to all your users instead.
What do you mean by ‘age appropriate application’?
This means that the age range of your audience and the different needs of children at different ages and stages of development should be at the heart of how you design your service and apply this code.
It also means you must apply this code so that all children are given an appropriate level of protection in how their personal data is used. There is flexibility for you to decide how to apply this standard in the context and circumstances of your online service. It will usually mean establishing (with a level of certainty that is appropriate to the risks to the rights and freedoms that arise from your data processing ) what age range your individual users fall into, so that you can tailor the protections and safeguards you give to their personal data accordingly, by applying the standards in this code. You should use your DPIA to help you assess this.
Alternatively, if you can’t or don’t wish to do this, you could choose to apply the standards to all your users instead. This is so that children are afforded some protection against the risks that arise from how their personal data is used, even if you aren’t sufficiently certain whether they are children or not.
Why is this important?
The ultimate aim of this code is to ensure that online services likely to be accessed by children are appropriate for their use and meet their development needs.
Understanding the age range of children likely to access the service – and the different needs of children at different ages and stages of development – is fundamental to the whole concept of ‘age-appropriate design’.
Children are individuals, and age ranges are not a perfect guide to the interests, needs and evolving capacity of each child. However, to help you assess what is appropriate for children broadly of that age, you can use age ranges as a guide to the capacity, skills and behaviours a child might be expected to display at each stage of their development. For the purposes of this code, we have used the following age ranges and developmental stages as a guide:
- 0 - 5: pre-literate and early literacy
- 6 - 9: core primary school years
- 10-12: transition years
- 13-15: early teens
- 16-17: approaching adulthood
There is no requirement for you to design services for development stages that aren’t likely to access your service, or to use these exact age ranges if you can justify why slightly different age groupings are more appropriate for your particular service.
Further information about relevant capacities, needs, skills and behaviours at each stage is set out at Annex B of this code for reference purposes, and where relevant throughout these standards.
You should also consider the needs of disabled children in line with any obligations you may have under the relevant equality legislation for England, Scotland, Wales and Northern Ireland.
The GDPR and DPA 2018 also specify that if you rely on consent for any aspects of your online service, you need to get parental authorisation for children under 13. If you do rely on consent as your lawful basis for processing personal data then these provisions have significant practical implications for you. Meeting the standards in this code should allow you to comply with these GDPR requirements in a proportionate way. See Annex C for full details.
How can we make sure that we meet this standard?
Consider the risks to children that arise from your data processing, and the level of certainty you have that you know the age of your users
You can implement this standard by following these steps:
- Think about the risks to children that would arise from your processing of their personal data. Your DPIA will help you to do this. You may wish to take into account factors such as: the types of data collected; the volume of data; the intrusiveness of any profiling; whether decision making or other actions follow from profiling; and whether the data is being shared with third parties. Both the ICO and the European Data Protection Board have also provided guidance on DPIAs which consider assessing risk in more detail.
- Consider how well you know your users. How certain are you that an individual user is an adult or a child? How confident are you about the age range your individual child users fall into?
- Decide whether the level of certainty you have about the age of your individual users is appropriate to the risks that arise from your data processing.
- If it is, then you can apply the rest of the standards in this code to your child users only.
- If it isn’t, then decide whether you prefer to:
- reduce the data risks inherent in your service;
- put additional measures in place to increase your level of age confidence; or
- apply the standards in this code to all users of your service (regardless of whether they have self-declared as an adult or a child).
How can we establish age with an appropriate level of certainty?
This code is not prescriptive about exactly what methods you should use to establish age, or what level of certainty different methods provide. This is because this will vary depending on the specifics of the techniques you use. We want to allow enough flexibility for you to use measures that suit the specifics of your individual service and that can develop over time. However you should always use a method that is appropriate to the risks that arise from your data processing.
Some of the methods you may wish to consider are listed below. This list is not exhaustive. Other measures may exist or emerge over time. In assessing whether you have chosen an appropriate method, we will take into account the products currently available in the marketplace, particularly for small businesses which don’t have the resources to develop their own solutions.
- Self-declaration – This is where a user simply states their age but does not provide any evidence to confirm it. It may be suitable for low risk processing or when used in conjunction with other techniques. Even if you prefer to apply the standards in the code to all your users, self-declaration of age can provide a useful starting point when providing privacy information and age appropriate explanations of processing (see ‘What does applying the standards to all users mean in practice?’ for more detail).
- Artificial intelligence – It may be possible to make an estimate of a user’s age by using artificial intelligence to analyse the way in which the user interacts with your service. Similarly you could use this type of profiling to check that the way a user interacts with your service is consistent with their self-declared age. This technique will typically provide a greater level of certainty about the age of users with increased use of your service. If you choose to use this technique then you need to:
- tell users that you are going to do this upfront;
- only collect the minimum amount of personal data that you need for this purpose; and
- don’t use any personal data you collect for this purpose for other purposes.
- Third party age verification services – You may choose to use a third party service to provide you with an assurance of the age of your users. Such services typically work on an ‘attribute’ system where you request confirmation of a particular user attribute (in this case age or age range) and the service provides you with a ‘yes’ or ‘no’ answer. This method reduces the amount of personal data you need to collect yourself and may allow you to take advantage of technological expertise and latest developments in the field. If you use a third party service you will need to carry out some due diligence checks to satisfy yourself that the level of certainty with which it confirms age is sufficient (PAS standard 1296 ‘Online age checking’ may help you with this), and that it is compliant with data protection requirements. You should also provide your users with clear information about the service you use.
- Account holder confirmation - You may be able to rely upon confirmation of user age from an existing account holder who you know to be an adult. For example, if you provide a logged-in or subscription based service, you may allow the main (confirmed adult) account holder to set up child profiles, restrict further access with a password or PIN, or simply confirm the agerange of additional account users.
- Technical measures – Technical measures which discourage false declarations of age, or identify and close under age accounts, may be useful to support or strengthen self-declaration mechanisms. Examples include neutral presentation of age declaration screens (rather than nudging towards the selection of certain ages), or preventing users from immediately resubmitting a new age if they are denied access to your service when they first self-declare their age.
- Hard identifiers – You can confirm age using solutions which link back to formal identify documents or ‘hard identifiers’ such as a passport. However, we recommend that you avoid giving users no choice but to provide hard identifiers unless the risks inherent in your processing really warrant such an approach. This is because some children do not have access to formal identity documents and may have limited parental support, making it difficult for them to access age verified services at all, even if they are age appropriate. Requiring hard identifiers may also have a disproportionate impact on the privacy of adults.
We recognise that methods of age assurance will vary depending on whether the service is used by authenticated or non-authenticated users (eg whether users are logged in) and that the risks may also vary in this context.
What if we need to collect personal data in order to establish age?
You may be able to collect and record personal data which provides an assurance of age yourself. If so, remember that you need to comply with data protection obligations for your collection and retention of that data, including data minimisation, purpose limitation, storage limitation and security obligations.
The key to this is making sure that you only collect the minimum amount of personal data you need to give you an appropriate level of certainty about the age of your individual users, and making sure you don’t use personal data collected for the purposes of establishing or estimating age in order to conform to this code for other purposes.
For example, if you use profiling to help you estimate the age of individual users so that you can apply the standards in this code, then you can use that profile information to ensure that you:
- provide age appropriate privacy information and nudges;
- provide high privacy settings for child users by default; and
- don’t serve children content deemed detrimental to their health and wellbeing.
You can’t however simply re-purpose that information for other purposes, such as targeting children with advertising for products you think they might like, or sending them details of ‘birthday offers’. If you want to profile children for this purpose then you need their consent. See the section of this code on profiling for further detail.
We recognise there is a tension between age assurance and compliance with GDPR, as the implementation of age assurance could increase the risk of intrusive data collection. We do not require organisations to create these counter risks. However, age assurance and GDPR are compatible if privacy by design solutions are used.
Age-assurance tools are still a developing area. The Commissioner will support work to establish clear industry standards and certification schemes to assist children, parents and online services in identifying age-assurance services which comply with data protection standards.
What does applying the standards to all users mean in practice?
If you don’t have a level of certainty about the age of your users that is appropriate to the risks to children arising from your data processing, then your alternative is to apply the standards in the code to all users. This should mean that even if you don’t really know how old a user is, or if a child has lied about their age, children will still receive some important protections in how their personal data is used.
However, it doesn’t mean that you have to ignore any information you do have about the user’s age, or that adult users have to be infantilised. It just means that all users will receive some basic protections in how their personal data is used by default.
You should apply the standards in the code in a way that recognises both the information you do have about the users age and the fact that your level of confidence in this information is inadequate to the risks inherent in your processing. For example, providing privacy information that is appropriate to the self-declared age of the user, but giving them the option to access versions written for different age groups as well.
Further reading outside this code