Age-Assurance Assessment

This is an internal accountability record. It explains how vAMSYS approaches age on the Services, and why that approach is proportionate. We keep it with our Privacy Policy and our DPIA. It is not part of our contract with you, but it supports the age commitments in the Terms of Service §2 (Eligibility and age) and what we say about age-assurance in the Privacy Policy. Words defined in the Terms of Service — such as User, Pilot, Owner, VA Staff, Virtual Airline (VA), Services and Team vAMSYS — have the same meaning here.

§1 Context

vAMSYS is a Virtual Airline management platform for people who fly flight simulators as a hobby. It is a niche, specialist tool: Owners run a Virtual Airline, Pilots log simulated flights, and VA Staff help administer rosters. There is no game, no avatar play, no toy-like or cartoon styling, and nothing designed to entertain or appeal to children, and we do not market to children or to a youth audience. The Services are intended for adults (18+).

We are, however, realistic about who flies flight simulators. Flight simulation is a hobby with a genuine under-18 following, and many of our users arrive from the simulator games themselves — Microsoft Flight Simulator, X-Plane and similar titles on Windows, Xbox and other platforms — which are played by a meaningful number of minors. We therefore do not assume, and do not claim, that children never access the Services. It is realistic to expect that a non-insignificant number of under-18s access vAMSYS despite our 18+ rule.

This assessment records how we have thought about that, the measures we have in place, and how we would escalate them if the risk changed.

§2 The requirement

Our Terms of Service set the minimum age. Under the Terms of Service §2 (Eligibility and age), the Services are for adults: a User must be at least 18 years old, and by using the Services they confirm that they are 18 or over. 18+ is the intended audience and the contractual rule; it is not, by itself, a claim that no under-18s are present.

§3 Our current approach

• Self-declaration at registration. When someone registers, they confirm they are 18 or over (Terms of Service §2). We rely on that declaration as the entry rule.

• No date of birth collected. We do not ask for or store a date of birth, and we hold no other age data. This is a data-minimisation choice — but we acknowledge its trade-off: because we do not hold age data, we cannot single out individual minors for special handling. We address that trade-off in the escalation ladder in §5.

• No hard age verification (today). We do not run identity-document checks or third-party age-estimation. As explained in §4 and §5, that level of friction and additional data collection is not proportionate for a low-value, low-risk niche tool at present — but it sits on our escalation ladder if the risk profile changes.

• Removal of any under-18 account on discovery. If we learn that a User is under 18, we remove that account.

• Protective by design for everyone (which protects any minors present). We run no behavioural profiling and no targeted or behavioural advertising; we process minimal personal data; we hold no special-category data; the clean, professional content standard in the Acceptable Use Policy §3 keeps the Services free of sexual, violent, hateful or extremist material; and our privacy information is written in plain language. These protections apply to all Users, so they also protect any under-18s who are present.

§4 Assessment — 'likely to be accessed by children'

Two frameworks are relevant: the ICO Age Appropriate Design Code (the Children's Code, under the UK GDPR) and the Online Safety Act 2023 (OSA).

4.1 The Children's Code

The Children's Code applies where a service is likely to be accessed by children (anyone under 18). This is a deliberately low threshold: it does not require a service to be designed for, or mainly used by, children — a more-than-insignificant likelihood of access is enough, even where the terms say 18+ and there is no child-directed marketing.

Conclusion (Children's Code). Given flight simulation's well-known under-18 following and the clear pathway into the hobby from the simulator games, we accept that the Services are likely to be accessed by a non-insignificant number of children, despite the 18+ rule. We do not rely on a "not likely to be accessed by children" argument. We therefore treat the Children's Code as engaged and conform to it so far as it applies to an adult-oriented service. Our existing design already meets much of its substance — data minimisation, no profiling, no behavioural or targeted advertising, a high-privacy posture, a clean content standard, plain-language transparency, and no special-category data — and we keep 18+ as the intended audience and remove identified under-18 accounts. We have judged hard age verification disproportionate at present (it would add significant friction and require us to collect more personal data, including age and identity data we have deliberately chosen not to hold), and instead rely on the protective design plus removal-on-discovery, with the documented escalation path in §5 if the risk increases or a regulator expects more.

4.2 The Online Safety Act 2023

vAMSYS is an in-scope user-to-user service (Users can post content other members see within a VA), and we do not rely on an out-of-scope argument. Two points:

• Illegal-content duties apply to every in-scope service regardless of children's access: an accessible reporting and takedown route (Terms of Service §7.2 and §7.3), human review of enforcement (§8.3), and a documented illegal-content risk assessment (see our OSA position statement).

• Children's access. Consistent with §4.1, we accept children are likely to access the Services. We recognise that self-declaration is not "highly effective age assurance" (HEAA) and we do not claim it is. We apply proportionate child-safety measures appropriate to a small, low-risk service — the clean content standard, the protective-by-design data practices, and removal-on-discovery — rather than HEAA, and we maintain the escalation ladder in §5.

§5 Risk, mitigations, and our escalation ladder

The core risk is that a minor accesses the Services despite the 18+ rule and a false self-declaration. We assess this as low-harm but real: the Services hold minimal data, run no profiling or targeted advertising, expose no age-inappropriate content (Acceptable Use Policy §3), and any identified under-18 account is removed.

We hold our age measures as a graduated ladder, so we can escalate proportionately if our risk profile changes or a regulator expects more. We are currently at Tiers 0–1.

• Tier 0 — baseline (in place): 18+ rule; removal of identified under-18s; data minimisation; no behavioural profiling; no targeted or behavioural advertising; clean/professional content standard; no special-category data; plain-language privacy information.

• Tier 1 — light measures: a neutral self-declared age step at sign-up; high-privacy defaults and "no nudge" design; a clear route to report a suspected under-18 account, acted on; and a children's-risk assessment carried out as part of our DPIA.

• Tier 2 — moderate measures: collecting a self-declared age or age-band so that likely-minors can be identified and given age-appropriate handling (stricter defaults, switching off higher-risk features such as public profiles, messaging or third-party connections, and no marketing). This would reverse our current no-age-data position, and we would only take it if proportionate to the risk.

• Tier 3 — strong measures: highly effective age assurance (third-party age verification or age-estimation). This carries real friction, cost, and additional personal-data collection and a new processor; it is aimed primarily at high-risk or age-restricted services, which vAMSYS is not, so we would adopt it only if genuinely required.

Recording this ladder is itself part of our approach: it shows the measures we operate today and the proportionate steps we would take next.

§6 Conclusion and review

vAMSYS is an adult (18+) niche hobby service that, realistically, is likely to be accessed by some under-18s. We therefore treat the Children's Code and the OSA's children's-access considerations as engaged, rather than claiming children do not access us. Our minimal-data, no-profiling, no-targeted-advertising, clean-content design already substantially conforms to the protective intent of those regimes; we keep the 18+ rule and remove identified minors; we judge hard age verification disproportionate at present; and we maintain a documented escalation ladder (§5) and a children's-risk assessment within our DPIA. This assessment supports the age commitments in the Terms of Service §2 (Eligibility and age) and the age-assurance section of the Privacy Policy.

Review trigger. We will revisit this assessment if our risk profile changes — for example, if we add features, content or marketing that could appeal to or attract children, if the proportion of under-18 users grows materially, if we receive regulatory feedback, or on a relevant change in the law or in ICO/Ofcom guidance — and otherwise periodically.

Questions about this assessment can be sent to help@vamsys.co.uk.

Sign-off

Reviewed and approved on behalf of vAMSYS LTD.

Role: Data Protection Lead, Team vAMSYS

Date: [DATE — set on publication]