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:

Data	Retention
Access logs (IP, geolocation, VPN/proxy/risk)	12 months, then the geolocation, VPN/proxy/risk, device and network details are deleted for everyone. Where the account is, or has been, subject to a ban or restriction, we also keep the IP address and its link to the account for as long as necessary to prevent evasion; otherwise that link is not kept beyond 12 months
API request logs	90 days
Billing records and invoices	6 years (HMRC legal obligation)
Proof of marketing consent	~2 years after consent is withdrawn
Banned or restricted User accounts	Not anonymised or deleted while the ban/restriction applies. Kept intact — not reduced to a minimal identifier — for as long as necessary to enforce it, including for duplicate-account matching and human review of the decision
Pilot removal	Restorable by the VA for up to 12 months; after 12 months, if the removal was not a ban or permanent removal, the pilot record is removed and the pilot's flight activity is transferred to the "vAMSYS Robot" system account and de-identified. Flight reports and bookings are not deleted at removal — a report still awaiting the pilot's reply is closed and annotated to record that no reply is coming, and the reports then follow the same path as the rest of the pilot's flight activity. If the removal was a ban or permanent removal, the pilot record is instead kept intact — not transferred or de-identified — in the same way as a banned User account, for as long as necessary
User-account deletion	Set inactive ("frozen"); after a 60-day reversal window, if the account is not, and has not been, subject to a ban or restriction, we anonymise it — irreversibly, with no value retained that could match a future sign-up back to the individual. If the account is or has been subject to a ban or restriction, it is excluded from this process — see "Banned or restricted User accounts" above
VA closure (subscription ends, not renewed)	The VA's data is retained for a restore window of up to 60 days. If the VA is not restored and resubscribed within it, the VA's records — including its pilot records and the flight reports filed at that VA — are permanently deleted. The Pilots' own User accounts are unaffected and follow their own lifecycle above. Billing records are retained for 6 years under the HMRC obligation, and enforcement records under §3.3
Pilot Account Reset (pilot-initiated, where the VA enables it)	The pilot's bookings, flight reports and analytics are transferred to the "vAMSYS Robot" system account and de-identified, while the pilot keeps their User account and VA membership. Immediate and irreversible — no reversal window, and no value is retained that could link the flying back to the individual
Unverified accounts that never joined a VA	Hard-deleted after 14 days

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

#	Risk
R1	Over-retention of IP and access-log data — keeping IP/geolocation/risk data longer than needed, or retaining ban-record IPs indefinitely without justification, intrudes on individuals beyond what security requires.
R2	Wrongful or opaque enforcement affecting access — a person could be restricted, suspended or removed in error, or without understanding why or how to challenge it, affecting their access to the Services.
R3	A VA misusing Pilot data — once a VA receives Pilot data (by viewing the roster, via the Pilot API, or by export), it could use it beyond operating the VA — for example, harvesting emails or marketing without consent.
R4	A data breach — unauthorised access to or loss of the identity, contact, billing or access-log data we hold.
R5	Residual transfers to Stripe and ProxyCheck.io — billing data processed by Stripe, and IP addresses sent to ProxyCheck.io, are processing outside our own systems and need a sound basis and minimisation.
R6	Under-18 access — despite the 18+ rule, some children are likely to access the Services (flight simulation has an under-18 following), and self-declaration does not prevent it; a minor's data could be processed, or a minor exposed to unsuitable content.

§5 Measures to reduce each risk

Risk	Measures
R1 Over-retention of IP/access data	Defined retention: for accounts with no ban or restriction, access-log enrichment fields are deleted at 12 months and the account itself is anonymised at 60 days with no matchable identifier retained; API request logs pruned at 90 days; cleanup jobs to enforce these limits. For accounts that are or have been subject to a ban or restriction, we keep the account and the related access-log IP intact for as long as necessary to prevent ban-evasion, with the legitimate-interests rationale in §3.3 — a deliberate, disclosed exception, not an oversight. The no-retention, on-demand IP check (§3.5) further reduces exposure.
R2 Wrongful or opaque enforcement	A Team vAMSYS person decides to restrict, suspend or remove; automated systems then give effect to that decision — applying the restriction to the person's access, accounts and new sign-ups that match the restricted person's signals (such as a shared IP), consistent with Privacy Policy §11 and Terms of Service §8.2. Because that can amount to an automated restriction, we provide the UK GDPR Article 22A–22C safeguards: notice, the category of reason, and the right to human review and to contest the decision (Terms of Service §8.3).
R3 A VA misusing Pilot data	The controller-to-controller Data Sharing Agreement with each VA binds a VA's use of the data it receives; the no-bulk-roster-export control (§3.5); the contractual prohibition on harvesting or off-purpose use (Terms of Service §11.2 (How a VA may use Pilot data) and Acceptable Use Policy §7 (Other users' data and privacy)); marketing only via the consented facility (§3.4); and enforcement against a VA that misuses data (Terms of Service §8).
R4 A data breach	Encryption, including encrypted backups on Cloudflare R2 (EU); access controls and least-privilege; self-hosted error monitoring; UK/EEA hosting; and a breach-response process — as controller, notification to affected individuals and the ICO where the law requires, plus notice to a VA without undue delay (target 72 hours) where a breach affects data it has received from us (Terms of Service §11.3 (Personal-data breaches)). Team vAMSYS support accounts can access every VA and their sign-ins are recorded like any other; a VA cannot remove them — this is disclosed (Terms of Service §3.6 (Pilot usernames) and §11.8 (International transfers, sub-processors and Team vAMSYS), and in the Privacy Policy).
R5 Residual Stripe / ProxyCheck.io transfers	Stripe processes billing data under its own DPA, UK Addendum and SCCs (the standard payment-processor route), and we minimise what we send (billing address and card descriptor only). ProxyCheck.io receives only an IP address, on-demand, for a momentary check, queried with the no-logging option so nothing is retained. All other processing stays within the UK/EEA.
R6 Under-18 access	Treated as in scope; the Children's Code is engaged (age-assurance assessment). Protective-by-design practices — data minimisation, no profiling, no targeted advertising, no special-category data, and the clean content standard (Acceptable Use Policy §3) — protect all Users including any minors; identified under-18 accounts are removed; and we hold a documented escalation ladder of further age measures (age-assurance assessment §5). Hard age assurance is judged disproportionate at present for a low-risk niche service.

§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

Assessment	Lightweight DPIA for the vAMSYS Services
Outcome	Residual risk low / acceptable; processing may proceed
Owner of this record	Data protection lead, vAMSYS LTD
Approved by	Director, vAMSYS LTD
Date	5 July 2026
Next review	On material change to the processing, or otherwise periodically