What the "Children's Code" means for your organisation

The Children’s Code (or Age Appropriate Design Code to give its formal title) is a data protection code of practice for online services, such as apps, online games, and web and social media sites, likely to be accessed by children. It came into force on 2 September 2020 with a 12 month transition period to give organisations time to prepare - meaning it will be in force in four months time.

Who needs to know about the Age Appropriate Design Code?

Anyone that designs or develops online services will need to consider whether the Code applies to them. This includes services such as:

  • apps,
  • connected toys and devices (including any devices which are likely to be used by a child),
  • search engines,
  • social media platforms,
  • streaming services,
  • online games,
  • news or educational websites and
  • websites that offer goods or services over the internet.

The Code does not just apply to services specifically directed at children. If your service is likely to be used by anyone under the age of 18, then the Code will apply.

What is the Age Appropriate Design Code?

The Information Commissioner's Office has stated that use of children’s data is one of its regulatory priorities and that complying with the standards set out in the Code is a key measure for demonstrating compliance with data protection laws.

Key to the Code is the principle that the best interests of the child should be the primary consideration when designing and developing apps, games, connected toys/devices and websites that are likely to be accessed by children.

The Code applies to personal data collected directly from children as well as “inferred data” about a child. The Code applies to both new and existing services, so providers of an existing service must start preparing now in order to be ready to comply with the Code in September 2021.

Does it apply to all services?

The Code applies to “information society services” that are “likely” to be accessed by children. The code follows the approach in the United Nations Convention on the Rights of the Child in stating that anyone under 18 is a child.

This does not mean all services that children could possibly access are covered. The factors taken into account include:

  • the nature and content of the service,
  • whether it has particular appeal for children,
  • the way the service is accessed, and
  • any measures that are in place to prevent children from accessing the service.

The Code applies if the online service is based in the UK, and to any organisation based outside the European Economic Area if they offer services to users in the UK or monitor their behaviour in the UK.

What are the standards?

The Code includes 15 standards of age-appropriate design, which are summarised below.

1. Best interests of the child

The best interests of the child must be the primary consideration when creating an online service likely to be accessed by a child. This requires considering the needs of child users, and deciding how those needs can be best supported through the way the service is designed to process their personal data.

Organisations can still pursue their own commercial interests, although where there is a conflict the ICO’s view is that a child’s right to privacy will outweigh those considerations.

2. Data Protection Impact Assessments (DPIA)

If an online service is likely to be accessed by children then you should have a DPIA to assess and mitigate the risks to children which arise from the data processing. An existing DPIA under GDPR is unlikely to be sufficient and organisations will need to assess and document their compliance with the Code. The DPIA should include an explanation of how each of the standards of the Code have been complied with.

The ICO expects larger organisations to conduct some form of consultation with children and parents in most cases. If the organisation considers it is not possible to consult or it is unnecessary or wholly disproportionate, that decision should be recorded in the DPIA. However, the ICO’s view is that it is usually possible to conduct some form of market research or user feedback.

3. Age-appropriate application

The age range of the user should be established so that the protections and safeguards are tailored to the age of the child. If this isn’t possible or an organisation does not want to do this, the Code states you should:

  1. reduce the risks to personal data across the whole service;
  2. put in place additional measures to increase the level of confidence in the age of the user; or
  3. apply the standards of the Code to all users

The Code outlines a list of age verification methods to consider:

  1. self-declaration without evidence
  2. use AI to estimate the age of the user
  3. use a third party age verification service - while acknowledging the risks around accuracy and dat processing inherent in this approach
  4. account holder confirmation when possible
  5. technical measures to strengthen self-declaration of age such as preventing users from immediately submitting a new age if they are initially denied access
  6. formal identity documents such as a passport

The Code states that personal data obtained to verify age cannot be used for other purposes, such as targeting children with advertising or sending details of “birthday offers”.

4. Transparency

Child-friendly explanations should be provided alongside terms, policies and community standards. The information should be presented in a child friendly way which is likely to appeal to the age of the child accessing the service, including:

  • diagrams,
  • cartoons,
  • graphics,
  • video/audio, or
  • interactive content.

Information should be tailored to the age of the child. The age ranges set out in the Code are:

  • 0-5 years (pre-literate and early literacy),
  • 6 to 9 years (core primary school years),
  • 10 to 12 (transition years),
  • 13 to 15 (early teens) and
  • 16 to 17 (approaching adulthood)

If user testing is not conducted, organisations should document the reason why in the DPIA.

5. Detrimental use of data.

Children’s personal data should not be used in a way that has been shown to be detrimental to their well-being, or goes against industry codes of practice, Government advice or other regulatory provisions. In addition, personal data shouldn't be processed in ways that have been formally identified as requiring further research or evidence to determine whether they are detrimental to the health and well-being of children. For example, following advice from the UK Chief Medical Officers, features that incentivise children to stay engaged such as in-game advantages are unlikely to comply with the fairness principle under GDPR.

6. Policies and community standards

Organisations are expected to uphold their own privacy policies, age restriction, content policies and behaviour rules/community guidelines. If you say that you actively monitor user behaviour then you need to do so.

In addition, if you rely on “back end” processes such as user reporting to identify breaches of user policies and standards, this should be made very clear. It is unlikely that adopting a light touch or back end only process to monitor and enforce user policies and standards would be sufficient if there are high risks to children.

7. Default settings

The default settings should be “high privacy”, unless there is a compelling reason which can be demonstrated for a different default setting, taking into account the best interests of the child. Age-appropriate prompts should be provided at points where a child attempts to change a privacy setting, in order to mitigate risk. Children should not be “nudged” towards selecting a lower privacy setting.

8. Data minimisation

Only the minimum amount of personal data should be collected and retained in order to provide the element(s) of the service that the child is actively and knowingly engaged in. It will be necessary to differentiate between each element of the service and consider what personal data is needed and how long it is needed for.

Children should be given separate choices over which elements they wish to activate. The Code states that this is particularly important for processing personal data to enhance, improve or personalise the user experience beyond providing the core service.

Processing children’s personal data for providing the core service and improvements/personalisation should not be bundled together.

9. Data sharing.

Children’s personal data should not be disclosed unless there is a compelling reason that can be demonstrated for doing so, taking into account the best interests of the child.

10. Geolocation

Options for collecting geolocation data should be turned off by default, unless there is a compelling reason which can be demonstrated for geolocation to be switched on by default, taking into account the best interest of the child. Any geolocation services that are additional to the core service should be subject to a separate privacy setting.

When location tracking is active, an obvious sign should be provided to the child. Options that make a child’s location visible to others must revert to “off” by default at the end of each session.

11. Parental controls

The child must be given age-appropriate information about any parental controls. The information should be tailored to the age range of the child, and could include audio/video materials to provide this information to children, as well as resources for parents to explain the service and privacy issues to their children.

Children must be told when they are being monitored if the service allows the parent or carer to monitor the child’s behaviour online or track their location.

12. Profiling

Profiling should only occur if there are appropriate measures in place to protect the child from any harmful effects.

Options which use profiling should be switched “off” by default, unless there is a compelling reason which can be demonstrated for profiling to be on by default, taking into account the best interests of the child.

If profiling is essential to the core service, a privacy setting is not required, although this is interpreted narrowly as the profiling must be “completely intrinsic to the service”. Therefore, most profiling should be subject to a privacy setting. Separate privacy settings should be provided for each different type of profiling, and a standard purpose like “providing a personalised service” are in the ICO’s view not specific enough.

13. Nudge techniques

Nudge techniques should not be used to encourage children to provide data or lower their privacy protections. The Code states that you should not exploit unconscious psychological processes or use nudge techniques that might lead a child to lie about their age.

However, pro-active nudges that support the development needs, health and wellbeing of the child are encouraged.

14. Connected toys and devices

Connected toys or devices must include effective tools to enable compliance with the Code. This also  applies to devices obviously intended for children such as connected toys, but is much wider and applies to any connected device likely to be used by multiple users of different ages including children, e.g. “home hub” interactive speakers.

In practice, the Code recommends ensuring that by default the service is suitable for use by children, and providing user profile options for regular users to support use by adults or tailor the service to the age of the particular child.

15. Online tools.

Prominent and accessible tools should be provided to help children exercise their data protection rights and report concerns

How can an organisation prepare for September 2021?

Organisations should assess whether the Code applies to their existing services. If the Code does not apply, the ICO expects that organisations document the reasons for this decision. If the Code does apply, the ICO expects organisations to be prepared to demonstrate how they comply.

It will therefore be important to document how you have complied in practice with the requirements of the Code, and be able to provide the ICO with copies of relevant DPIAs, policies, training and records of processing if requested.

Some practical steps to prepare include:

  • Updating DPIA templates to include elements demonstrating how the requirements of the Code have been met, as well as conducting/updating DPIAs on existing services and consulting with children and parents
  • Reviewing existing or introducing new age verification mechanisms to any service
  • Reviewing existing or creating new age-appropriate resources
  • Ensuring age-appropriate tools are in place for children around data protection
  • Ensuring any necessary changes are made including default privacy settings, profiling and nudge techniques

What are the penalties?

The ICO has stated that where it seems that harm or potential harm to children it is likely it will take more severe action against a company than it otherwise would for other types of personal data.

If the ICO decides that an organisation has not complied with the standards in the Code, it is more likely to allow the organisation time to make changes to the relevant service to comply if the organisation has a well-documented and reasoned case.

However, the ICO is more likely to take formal enforcement action if:

  • proper steps have not been taken to comply with the Code, and
  • there is clear evidence or constructive knowledge that children are likely to access the service, and
  • clear evidence of a significant risk from the use of children’s data.