Safeguarding

Age Appropriate Design (Children's Code)

How the Race platform meets the ICO Age Appropriate Design Code for users under 18.

Last updated: June 2026 4 min read
On this page
  • 1. Who this covers
  • 2. High privacy by default
  • 3. Data minimisation
  • 4. No nudge techniques
  • 5. Parental controls and transparency
  • 6. Wearables and health data
  • 7. Data protection impact assessment
  • 8. Profiling and marketing

1. Who this covers

The ICO Age Appropriate Design Code (the Children's Code) applies to online services that are likely to be accessed by people under 18 in the UK. Our Race platform, which supports junior sailors, squads, and youth coaching, is likely to be accessed by under-18s, so we treat the Children's Code as applying to it.

The guiding principle of the Code, and of how we build for young people, is that the best interests of the child come first. Where a design choice could go either way, we resolve it in favour of the child's privacy, safety, and wellbeing rather than in favour of engagement or data collection. This statement explains, in plain terms, how we put that principle into practice.

2. High privacy by default

Settings that could reduce a young person's privacy start switched off. A junior account is private out of the box, and the features that share data or connect a device stay inactive until someone deliberately turns them on.

  • Sharing of training logs, results, and media with anyone beyond the athlete's own coach and squad is off until switched on.
  • Wearable device linking is off until the athlete, and a parent where consent is required, opts in.
  • Any feature that widens who can see a young person's data presents the privacy implications first, and defaults to the more private choice.

Turning a feature on is always a clear, separate action, and it can be turned off again at any time.

3. Data minimisation

We collect only the personal data that a junior account actually needs to work. For Race, that means the data required for three purposes: the athlete's training log, coaching and feedback, and squad administration.

  • We do not ask a young person for information that is not needed to deliver the feature in front of them.
  • Optional fields stay optional, and leaving them blank does not reduce the core experience.
  • Where a feature is switched off, we do not collect the data that feature would have used.

If a purpose ends, the data tied to it is no longer needed and is removed in line with our retention practices.

4. No nudge techniques

We do not use dark patterns or nudge techniques that push young people into weakening their own privacy or sharing more than they intended.

  • No pre-ticked boxes that opt a young person into sharing or data collection.
  • No design that makes the privacy-protective choice harder to find or harder to select than the less private one.
  • No guilt-based or reward-based prompts that pressure a child to switch protections off.

Privacy choices are presented neutrally, so that accepting and declining are equally easy.

5. Parental controls and transparency

Parents and guardians can see and control how their child uses Race through the parent portal. We explain what the platform does, and what controls are available, in language a young person and their parent can understand.

  • Linked parents can view the relevant parts of their child's account, review what is shared, and adjust or revoke settings.
  • Where a control or consent rests with the parent, the parent portal makes it clear and easy to act on.
  • Notices to young people are written in plain English, kept short, and shown at the point they are relevant.
Parental visibility is a control, not surveillance. We aim to give parents enough oversight to keep their child safe, while still respecting the young person's growing need for age-appropriate privacy.

6. Wearables and health data

Athletes can optionally link a wearable device (Garmin, Polar, Suunto, and more over time). Because health data is special-category data, we apply stricter consent thresholds for young people than we do elsewhere on the platform.

  • Under 16 (and under 18 in the United Arab Emirates, Saudi Arabia, Qatar, Bahrain, and Israel): a linked parent must grant consent before any wearable data flows. The athlete sees a waiting screen, and every linked parent can review and approve the request by email or in the parent portal.
  • 16 to 17 (where the jurisdiction permits): the athlete may self-consent through an explicit confirmation screen. Parents are notified, and they can revoke on the athlete's behalf from the parent portal.
  • 18 and over: the standard consent flow applies.

Either the young person or a linked parent can revoke consent at any time, and revocation takes effect immediately. Fuller detail on what we capture, coach visibility, and revocation is set out in our safeguarding statement.

7. Data protection impact assessment

We hold a data protection impact assessment (DPIA) for the wearable special-category processing on Race. The DPIA records the purposes, the risks to young people, and the measures we take to reduce those risks, including the consent thresholds, default-off design, and minimisation described above.

We review the DPIA when the wearable features change in a way that could affect young people, and we are happy to discuss it with parents, clubs, or the ICO on request.

8. Profiling and marketing

  • We do not profile young people for marketing purposes.
  • Junior accounts never receive marketing email.
  • We do not use a child's data to target advertising at them.

Where Race uses data about an athlete, it is to deliver the training log, coaching, and squad features they signed up for, not to market to them. Any change to this approach would be assessed against the best interests of the child before it went ahead.

Questions about young people's data?

Parents, guardians, clubs, and coaches can reach our safeguarding team directly.

safeguarding@fleetfixer.io
SafeguardingProtecting young people PrivacyHow we handle data SecurityHow we keep it safe