Data Protection Impact Assessment

This Data Protection Impact Assessment (DPIA) is an internal accountability record kept alongside our Privacy Policy. It supports — and does not change — our Terms of Service or any policy that forms part of them. 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. vAMSYS LTD (company number 09982167), 71-75 Shelton Street, Covent Garden, London, WC2H 9JQ, is the controller for the processing assessed below. You can contact us about it at help@vamsys.co.uk.

§1 Why we carried out this DPIA

We are not legally required to carry out a DPIA for every part of the Services, but we choose to keep a lightweight one because some of our processing is the kind that warrants a closer look. In particular:

• Systematic monitoring for security. Every sign-in is recorded in our access logs with the IP address, derived geolocation and network details. Where we need to assess whether a connection is a VPN, proxy or otherwise higher-risk, we check the IP with ProxyCheck.io on-demand — for example when investigating suspected abuse or ban-evasion — not as automatic enrichment of every sign-in. Access logging is a regular, systematic activity carried out to keep the Services secure and to prevent ban-evasion and fraud.

• Processing of member data at scale. The Services hold identity, contact, billing and operational data for a large community of Users and Pilots across many Virtual Airlines.

• Processing that can affect a person's access. Our enforcement processing can result in a person being restricted, suspended or removed from the Services (see Terms of Service §8 (Suspension, restriction and enforcement)). A decision of this kind has a real effect on the individual, so it deserves the safeguards we set out below.

Children. The Services are intended for adults (18+) and we remove accounts we find to belong to under-18s (Terms of Service §2 (Eligibility and age)). Realistically, however — given flight simulation's under-18 following and the pathway into the hobby from the simulator games — some under-18s are likely to access the Services, so we treat the risk to children as in scope, not excluded. We assess it in our age-assurance assessment (kept with this DPIA and the Privacy Policy), treat the Children's Code as engaged, and rely on protective-by-design practices (data minimisation, no profiling, no targeted advertising, the clean content standard in the Acceptable Use Policy §3) plus removal-on-discovery, with a documented escalation ladder. We collect no date of birth today (data minimisation) and process no special-category data. (Our enforcement does involve some automated restriction; we address that, and the Article 22A–22C safeguards we provide, in §3 and §5 — we do not claim it never occurs.)

§2 Description of the processing

2.1 Nature, scope, context and purpose

vAMSYS operates a Virtual Airline management platform on which Users run and join non-commercial flight-simulation hobby communities. We process personal data to:

• create and run User accounts, Pilot memberships and Virtual Airlines (the contract we have with you);

• operate and secure the Services, prevent fraud and ban-evasion, and protect Users and the platform;

• take subscription payments from Owners and keep the financial records the law requires;

• let Pilots optionally connect their own external accounts, and optionally generate operational flight plans (OFPs); and

• let a Pilot consent, per VA, to receive marketing from that VA through our consented marketing-export facility.

The Services are intended for adults (18+). We do not collect date-of-birth data or carry out age verification; we rely on self-declaration. We accept that a non-insignificant number of under-18s are likely to access the Services despite that rule, as documented in our age-assurance assessment kept with the Privacy Policy. We therefore treat the risk to children as in scope and the Children's Code as engaged (see §1 and risk R6). We rely on protective-by-design practices — data minimisation, no profiling, no targeted or behavioural advertising, no special-category data, and the clean content standard in the Acceptable Use Policy §3 — together with removal of identified under-18 accounts and a documented escalation ladder of further age measures (age-assurance assessment §5). We judge hard age assurance disproportionate at present for a low-risk niche service.

The lawful bases are set out in §3.2. The full, plain-language description for individuals is in our Privacy Policy.

2.2 The personal data, and the data subjects

The data subjects are Users (including those acting as Pilots, VA Staff and Owners) and visitors to our corporate site. The main categories of personal data are:

• Account identity — real first and last name, public display name, any previous name, and the system-allocated Pilot username;

• Contact — email address, and where given, phone, post code, city and country;

• Linked-account identifiers — identifiers and tokens for external accounts a User chooses to link (for example Discord, VATSIM, IVAO, POSCON, APOC, Navigraph, SimBrief);

• Authentication data — hashed password and two-factor secrets;

• Billing data (Owners only) — billing name, email and address, VAT identifier, and a card descriptor (card type and last four digits). We do not hold full card numbers or security codes; the payment processor holds those;

• Access-log data — per sign-in: IP address, derived geolocation, network/organisation and user-agent; plus, from on-demand ProxyCheck.io checks, a VPN/proxy/risk assessment for an IP where one is needed;

• API request logs — for VA integrations: request metadata including IP address, user-agent and response details;

• Operational and flight activity — bookings, flight reports, live position reports, points, ranks and similar, created by a Pilot's activity within a VA;

• Enforcement and moderation records — restriction, ban and name-review records, and staff notes; and

• Corporate-site data — feedback submissions and changelog newsletter subscriptions.

2.3 Recipients and sub-processors

We use a small set of external sub-processors to run the Services. Each receives only the data it needs, for the stated purpose:

• Stripe — subscription billing for Owners. Stripe holds the card data; we hold only the billing address and a card descriptor. Stripe processes billing data under its own Data Processing Addendum, UK Addendum and Standard Contractual Clauses (the standard payment-processor route).

• Mailgun (EU region) — transactional email (for example, verification and reset messages and operational notices).

• ProxyCheck.io — an on-demand VPN/proxy/risk check of an IP address (for example during an abuse or ban-evasion investigation), not automatic enrichment of every sign-in. We send an IP address for a momentary, real-time check and query with the provider's no-logging option, so the provider retains nothing (see §3.3).

Two more are third-party sub-processors (not "our own infrastructure"), and both are US-parented, so although we use their EU regions we rely on each provider's data-processing terms plus the UK Addendum/SCCs (or IDTA) as the transfer safeguard:

• DigitalOcean Spaces (EU region) — object storage for OFP PDFs (which carry a pilot name) and images shown within a VA (such as a VA logo or a VA Staff image); and

• Cloudflare (EU region) — DNS, edge delivery and PIREP position-report ingestion (no identity data), plus encrypted database backups on Cloudflare R2.

The following are our own infrastructure, in the UK/EEA: a self-hosted Sentry instance (error monitoring, on our own servers, not Sentry's hosted service) and our primary database (EEA).

We process personal data in the UK/EEA; the only transfers outside it are to the US-parented providers above (and Stripe / ProxyCheck.io, §2.5), each under appropriate safeguards.

Services the User connects are not our sub-processors. Where a Pilot links their own existing account with Navigraph, Discord, VATSIM, IVAO, POSCON or APOC, that account is governed by those services' own terms. OFP generation through SimBrief/Navigraph is optional; the only outbound flow is the pilot's name and username, sent to generate the OFP.

VA recipients. A VA can view the data it needs to run its roster (which vAMSYS controls) and, where a Pilot consents, receives Pilot data through the Pilot API. A VA controls only the data it holds itself — the data it provides to invite people, and the data it receives through the Pilot API or by export. Our controller-to-controller relationship with VAs is described in §3.1.

2.4 Retention

We keep personal data only as long as we need it:

Account deletion is reversible within the window, then results in genuine anonymisation — not partial pseudonymisation — for accounts with no ban or restriction. In summary: a User account with no ban or restriction is anonymised after the 60-day reversal window; a banned or restricted account is excluded from that process and kept intact for as long as the restriction applies; a removed pilot is restorable by the VA for up to 12 months, after which — if the removal was not a ban or permanent removal — the pilot record is removed and that pilot's flight activity is transferred to the "vAMSYS Robot" system account and de-identified; a pilot removed by ban or permanent removal is, like a banned User account, kept intact rather than transferred or de-identified; where a pilot uses the optional Account Reset, their flying is transferred to the "vAMSYS Robot" system account and de-identified immediately and irreversibly, while their account remains; and where a VA closes and is not restored within its 60-day window, the VA's records — its pilot records and the flight reports filed at it — are permanently deleted, leaving the Pilots' own User accounts untouched.

Banned or restricted accounts are described honestly: we do not anonymise, pseudonymise or hash them — the account and its identifying data, including the plaintext IP address, are kept intact for as long as necessary for security and to prevent ban-evasion.

Backups. Encrypted backups on Cloudflare R2 (EU) are kept on a 2-week rolling cycle (point-in-time recovery and full backups, both retained for around two weeks) and then overwritten. Data removed from the live Services therefore persists in backups only until the cycle rotates (around two weeks), after which it is gone.

2.5 International transfers

We process personal data in the UK and the EEA. Some sub-processors, although we use their EU regions, are part of US-headquartered groups, which can amount to a transfer outside the UK/EEA. We rely on appropriate safeguards (each provider's data-processing terms plus the UK Addendum/SCCs or IDTA):

• Stripe — billing data, under Stripe's own Data Processing Addendum and the UK Addendum/SCCs.

• DigitalOcean (object storage) and Cloudflare (DNS/edge and encrypted R2 backups) — US-parented, used in their EU regions, under their DPAs and the UK Addendum/SCCs.

• ProxyCheck.io — an IP address sent on-demand for a momentary check, with the provider's no-logging option so nothing is retained (see §3.3).

We do not otherwise transfer personal data outside the UK/EEA in the course of providing the Services.

§3 Necessity and proportionality

3.1 Our roles (controllers)

vAMSYS is the controller of all personal data on the platform — both User identity, account, billing and access-log data and the operational/flight data a Pilot's activity creates. A VA does not control that data; using platform features (awarding points, setting scoring, leaving comments, removing registrations) is use of the Services, not control. A VA is a controller only where it holds personal data itself — the name and email it provides to invite people (Pilot Invite), and any data it receives through the Pilot API (with the Pilot's consent) or by export, in its own systems. vAMSYS and a VA are separate, independent controllers — not joint, and vAMSYS is not a VA's processor. This mirrors the Terms of Service §11.1 (Who controls what (the controller map)) and §11.2 (How a VA may use Pilot data).

3.2 Lawful bases

• Contract — creating and running User accounts and Pilot memberships, and providing the subscription to Owners.

• Legitimate interests — operating and securing the Services, preventing fraud and ban-evasion, protecting Users and the platform, and improving the product. Our legitimate-interests rationale for the security and IP processing is set out in §3.3.

• Consent — the marketing-export facility (§3.4), and the optional external account integrations and OFP generation a Pilot chooses to use.

• Legal obligation — keeping financial records, responding to lawful requests, and meeting our illegal-content duties.

3.3 Legitimate-interests rationale for the security and IP processing

We have a genuine interest in keeping the Services safe and in stopping a restricted person from simply making a new account. Logging sign-ins with the IP address, and checking an IP for VPN/proxy/risk on-demand when we investigate abuse, is an effective, proportionate way to detect ban-evasion, duplicate accounts and fraud, and there is no less-intrusive way to achieve the same protection. We balance this against the individual's interests by minimising what we collect and how long we keep it (§2.4, §5) and by using a no-retention IP check (below). For accounts with no ban or restriction, we anonymise fully once the retention period ends, rather than retaining a matchable identifier. Where an account is or has been subject to a ban or restriction, we keep it intact rather than reducing it, since minimisation there would undermine the enforcement purpose it exists for (Terms of Service §8.9 (Records we keep after enforcement)). Users reasonably expect a platform to protect itself from abuse in this way. We have concluded that our legitimate interest in operating a secure, abuse-resistant platform is not overridden by the rights and freedoms of data subjects, given the data minimisation for non-restricted accounts, the no-retention ProxyCheck check, and the limited, disclosed nature of the exception for banned or restricted accounts.

3.4 Marketing — consent, with the VA as controller

The only sanctioned marketing route is the consented marketing-export facility. The lawful basis is consent; it is recorded per VA, names the specific VA, and is freely withdrawable. The VA is the controller of the marketing it sends and carries the unsubscribe and compliance duty. Operational, safety and security emails are part of running the Services and need no separate consent. This mirrors the Terms of Service §11.4 (Marketing-export consent) and the Acceptable Use Policy §7 (Other users' data and privacy).

3.5 Data minimisation and key controls

• ProxyCheck.io no-retention check. We query ProxyCheck.io with the no-logging option, so the IP check is momentary and in-memory at the provider, which retains nothing. We use it on-demand, not as automatic enrichment of every sign-in. This is the least-intrusive way to get the risk signal we need.

• No bulk roster export. We do not provide a bulk export of a VA's roster or its Pilots' personal data. Data portability cannot be used by an Owner to mass-extract Pilots' personal data; where a VA has a genuine legal or regulatory obligation that needs specific member data, we provide it case by case. This mirrors the Terms of Service §4.3 (A VA's own legal obligations) and Terms of Service §11.9 (Your rights, and your data when you leave).

• Minimum billing data. We hold only a billing address and card descriptor; the card data sits with the payment processor.

• Minimum API exposure. The Operations API never exposes emails or contact details.

• Legal hold. In narrow circumstances — an active legal claim, dispute, investigation, or another legal reason — we may pause the deletion, anonymisation or log-scrubbing timelines above for as long as that ground applies, consistent with Article 17(3) UK GDPR. This is flagged per account by staff and logged, and applies on top of (not instead of) the ban/restriction exception above.

§4 Risks to individuals

§5 Measures to reduce each risk

§6 Residual risk and conclusion

After applying the measures in §5, we consider the residual risk to individuals to be low and acceptable. The processing is necessary and proportionate to operating and securing the Services; it rests on appropriate lawful bases; the data is minimised and retained for limited, defined periods; enforcement that can affect access is made by a person with notice and a right to human review; transfers are limited to the UK/EEA plus two narrow, well-controlled residual flows; and individuals can exercise the full range of UK GDPR rights, and complain to the Information Commissioner's Office (ICO, ico.org.uk), as described in our Privacy Policy.

We will review this DPIA when the processing materially changes — for example, if we add a new sub-processor or change a retention period — and otherwise periodically.

Sign-off