Privacy Policy

The short version

We are Innovology Ltd, trading as SailCoach. We run a sailing training platform used mostly by junior sailors, their coaches, their parents and their clubs.

Most of our users are children. That shapes everything below.

Three things are worth knowing before you read the detail:

1. We hold a lot about a sailor. Training notes, coach feedback, video of them sailing, goals, sometimes medical notes and an emergency contact, and precise GPS tracks of how they sailed a race.
2. We hold race results about people who have never used SailCoach. We collect published regatta results and GPS race tracks from public sources. Those contain the names of sailors — including children — who have never signed up with us. Section 5 is written for them. If that is you or your child, you can tell us to remove you and we will.
3. We are honest about what we have not built yet. This policy says where our controls are weaker than they should be. The previous version of our privacy page claimed we require parental consent for under-18s. That was not true of the system we had built. It is corrected here, and the honest position is in section 12.

This policy tells you what we collect, why, who sees it, how long we keep it, and what you can make us do about it. If you would rather read a shorter version written for sailors themselves, see Privacy for Young Sailors.

1. Who we are and how to contact us

Innovology Ltd, trading as SailCoach, is the data controller for the personal data described in this policy. Innovology Ltd is registered in England and Wales under company number 11778435, with its registered office at 20-22 Wenlock Road, London, England, N1 7GU. Our service is at https://sailcoach.app.

We acknowledge messages to [email protected] within five working days and respond in full within one month, which is the deadline UK GDPR sets for rights requests.

Clubs and coaches also make their own decisions

A coach decides what to write about a sailor. A club decides which children it puts on a squad list and what safety information it records about them. In data protection terms, that club or coach may be a controller in their own right for the content they create, alongside us. We are the controller for the platform and everything we do with the data across it. If a club needs a written arrangement with us setting out who is responsible for what, write to [email protected].

We have not appointed a Data Protection Officer

UK GDPR Article 37 requires a Data Protection Officer in three cases: where the controller is a public authority; where its core activities consist of regular and systematic monitoring of individuals on a large scale; or where its core activities consist of large-scale processing of special category data or criminal offence data.

Our assessment, honestly stated:

• We are not a public authority.
• Our processing of health data (medical notes) and criminal offence data (coach DBS records) is genuinely small: a few hundred short free-text fields across a small user base. That is not "large scale".
• The monitoring test is the one we do not find comfortable. Our core activity includes systematic performance profiling of sailors, and our race-results corpus covers tens of thousands of named people, most of them children. We do not think that crosses the Article 37 threshold, because the monitoring is of published competitive results rather than of individuals' behaviour, and because that corpus is neither special category nor criminal offence data. But it is a judgement call rather than an obvious answer.

So: no DPO is appointed, we do not believe one is legally required, and we keep that decision under review — formally, whenever we materially expand what we collect. Responsibility for data protection sits with the person who answers [email protected], and that mailbox is monitored.

We have not appointed a representative in the EU under Article 27. We do need one. The exemption in Article 27(2) is for processing that is occasional, excludes large-scale special category data and is unlikely to risk people's rights, and ours is none of those things. This is an overdue step, not an open question; it is on our DPIA risk register with a date. Until it is done, EU users should write to [email protected], and can complain to their own national supervisory authority (see section 16).

2. What we collect

This section is organised by who you are. Where the same data appears twice, it is because two different people can create it.

2.1 Everyone with an account

Two honest notes on analytics. First, nothing in the table above is collected unless you have accepted the analytics category — no identifier is minted and no event is sent. Section 15 and the Cookie and Storage Notice set out how we ask. Second, because the identifier belongs to a browser and not a person, a shared family computer can link two accounts' browsing together. Clearing it on sign-out limits that; our internal tooling flags when a merge appears to have happened rather than silently accepting it.

2.2 If you are a sailor

A child can be in our system without an account at all. A head coach can add a sailor to a squad list by name and date of birth, with a medical note, before that sailor or their parent has ever signed up. That is normal for how clubs run squads, and it means we hold data about children who have not agreed to anything. Those records are visible only to that club's coaches and administrators, and a parent can write to [email protected] to see or remove them.

2.3 If you are a coach

Everything in 2.1, plus:

2.4 If you are a parent or guardian

2.5 If you are a club administrator

Everything in 2.1, plus the club record itself (contact email, phone number, coordinates), and a log of the administrative actions you take.

2.6 If you have never signed up

We hold data about sailors who have no relationship with us at all. This comes from published race results and from public GPS race-tracking services. Section 5 deals with it in full and is the part of this policy written specifically for you.

2.7 Free text — the honest warning

A large amount of what we hold is free text that somebody types about somebody else. Coach notes, feedback, assessments, session notes, goal descriptions, skill notes and messages are all unbounded free-text fields, and nothing in the product stops a coach from typing anything at all into them.

That matters because the most likely place for sensitive information about a child to appear — an injury, a diagnosis, a family circumstance, a safeguarding worry — is a free-text box that was never designed to hold it. We do not scan, redact or classify those fields. Our Acceptable Use Policy sets rules for what coaches should and should not write; that is a rule, not a technical control, and we say so plainly.

2.8 What we do not collect

Stated negatively, because it is useful to know:

• No payment data. SailCoach is free to use and there is no payment provider connected to it. We hold no card details.
• No advertising or ad-tech. No Google Analytics, no Meta pixel, no advertising networks, no behavioural advertising of any kind. Nothing about you is sold or shared for advertising.
• No dietary, allergy, disability, injury or medication fields. If that information is in our system it is because somebody typed it into a free-text box.
• No ethnicity, race, religion, political opinion, trade union membership, sexual orientation or genetic or biometric data. Gender appears only where it was already a column in a published race result; we never ask you for it.
• No facial recognition. Video of sailors is stored and annotated, but it is never processed to identify anyone.

3. Health data and other special category data

Some of what we hold is what UK GDPR Article 9 calls special category data — data about health. It gets extra protection, and we need a specific condition to process it at all.

What it is, precisely:

1. Medical notes on a sailor's profile. Up to 1,000 characters, entered by the sailor or their parent.
2. Squad medical notes. Up to 500 characters, attached to a named child by their head coach. These often concern children who have no account.
3. Body weight records, where the sailor is a child. We treat these as health data about a child even though weight alone is not obviously special category data, because the cautious reading is the right one where children are involved.
4. Physical and mental ratings inside a private coach assessment. These are not health data as such — they are a coach's view of fitness and mindset — but they sit close enough to it that we handle them with the same care.

The conditions we rely on:

Three points of precision that matter:

• We do not use consent as our Article 6 basis here. A sailor cannot realistically refuse a club that asks for a medical note and still sail, so that consent would not be freely given and we are not going to dress it up as though it were. We do need explicit consent under Article 9, because no other condition is available to us — so the note is genuinely optional, no feature stops working without it, and deleting it removes it from the record. Withdrawing the Article 9 consent stops the processing whatever section 6 says.
• Who can give that consent. The UK sets the age of digital consent at 13 (section 9 of the Data Protection Act 2018), so for a sailor under 13 only a parent or guardian can give explicit consent to health data being recorded. Today the form does not check who is typing, and we have no way to prove that a note on an under-13's profile was entered by their parent. That is a gap; it is in section 12.
• Where we rely on the safeguarding condition, the Data Protection Act requires an appropriate policy document to be in place at the time of the processing, setting out how we comply with the data protection principles and what our retention and erasure policy is for that data. We do not yet have a document that meets paragraph 5(2) of Schedule 1 Part 4. Our Safeguarding Policy, Data Retention Schedule and published DPIA cover most of the ground but were not written for that purpose. Assembling them into the document the Act contemplates is an open action dated 31 December 2026 in the DPIA, and until it is done our reliance on the safeguarding condition is not secure.

Who can see a medical note: the sailor; the sailor's parent or guardian while the sailor is under 18; an administrator of the sailor's club; and us, where we have to. A coach who is merely connected to a sailor cannot see it.

A squad medical note is narrower, but not as narrow as it should be: it is readable by the squad's head coach and by every coach listed on that squad, on any day, whether or not they are running that session and whether or not the sailor is in their group. The day view shows a coach only the flags for sailors in their own group, but the underlying note is not gated that way. A squad roster shows only that a note exists, never its text. Narrowing this to the coach actually running the session is work we have not done, and a club should add a coach to a squad only when they need that access.

Giving us health information is optional. No feature of SailCoach stops working if you leave the field blank. If a club has asked you for a note, that is the club's decision as a controller in its own right — but it does not change our position: you can delete it, and we will not treat the account differently.

4. Criminal offence data — coach DBS records

We record DBS checks for coaches. Under the Data Protection Act 2018, criminal offence data — which includes a record that somebody has been DBS checked — needs its own condition.

Our condition: consent — paragraph 29 of Part 3 of Schedule 1 to the Data Protection Act 2018. A coach chooses to record their own check and upload their own evidence; we do not take it from anywhere else, and a coach can withdraw it and have it deleted. Our Article 6 basis is legitimate interests: parents and clubs are entitled to know whether an adult coaching children has been checked.

We do not rely on the safeguarding condition in Schedule 1 Part 2 paragraph 18 for this data. That condition is only available where the processing is carried out without the data subject's consent, and here the data subject is the coach, whose consent is the mechanism by which the record arrives. Because paragraph 29 is a Part 3 condition, the appropriate policy document requirement described in section 3 does not attach to it.

What we hold: the check type, a reference, the provider, an expiry date, an evidence file the coach uploads, and who at the club verified it. We do not receive or store the content of a disclosure certificate, and we do not hold conviction details.

Who can see it: the coach; administrators of the club that verifies it; a head coach for coaches working in squads they run, so that a lapsed check can be picked up. Not sailors and not parents.

An honest limitation. Recording a DBS check is not the same as enforcing one. Today, nothing in SailCoach blocks a coach without a current, verified DBS check from being assigned to a squad, messaging a sailor, or seeing a medical note. The check is a record, not a gate.

An older self-declared "background check" status used to sit on coach profiles. It can no longer be set or changed by anyone — the server strips it from any profile update — and it is no longer displayed. Values recorded before this release may still sit in the database and are being cleared. It was never verified by anyone and was never assurance of anything.

Two credential surfaces are still self-typed and unverified: the free-text "certifications" box on a coach's profile, and the qualifications list on a published coach page. Neither carries a marker saying so. The club-verified records described above are the only ones anybody has looked at. Marking every displayed credential as verified or unverified is outstanding work. Our Safeguarding Policy explains what clubs should do in the meantime.

5. Data we did not get from you

This section is for people who have never used SailCoach. If you sailed in a regatta whose results were published on a club or class website, or whose fleet was tracked by a GPS tracking service, we may hold data about you. You did not give it to us. UK GDPR Article 14 requires us to tell you the following.

5.1 What we hold

From published regatta results (HTML pages, PDFs, and scanned result sheets we read with optical character recognition), for each competitor row:

• Finishing rank, sail number, helm's full name, crew's full name, club, nationality, age group, gender where the results published it, boat class, every individual race score, and every penalty code (OCS, BFD, DSQ, RET and so on). We keep the original page for provenance.

From GPS race-tracking services:

• A boat identifier, sail number, boat name, the sailor's name where the service published it, and the full GPS track of the race — a chronological series of positions with heading and speed. From those tracks we compute performance metrics for every boat in the fleet, not only for our own users: start position, average and maximum speed, distance sailed, penalties and places gained or lost on each leg.

We then link those records together, and this is the step that changes their character:

• We build a record per sail number that carries every helm name ever seen on that number, across every event and every year.
• We cluster names across sail numbers using fuzzy name matching to build a single record per person.
• We compute a statistical skill rating over those records.

A published results page is a snapshot of one weekend. What we build from many of them is a multi-year record of one person's competitive career. We do not pretend those are the same thing.

Most of this data is about children. Our collection is heavily weighted towards the Optimist class, sailed by children aged roughly eight to fifteen.

5.2 Where we got it

The sites below are our automated sources. Results can also reach us because one of our users submitted a published file or link, and that route is the last row.

We do not currently identify ourselves to these sites, and you should know that before you read the balancing test below. Our crawlers present an ordinary browser user-agent, deliberately: several of these sites serve nothing at all to a client that does not look like a browser. One tracking provider's race-definition endpoint goes further — it answers a plain request with an authentication error, and we get past that by sending the origin and referrer of the provider's own public replay viewer. The consequence is that a site operator cannot presently see us in their logs as SailCoach, cannot block us by name, and cannot use robots.txt against us as a named agent.

We regard that as a weakness in the balance below, not a mitigation of it, and we are not going to count it in our favour. Moving to a named agent with a contact URL, and asking the tracking provider for proper access rather than presenting its viewer's headers, are both on our list.

5.3 Our lawful basis, and the balancing test behind it

Our basis is legitimate interests, UK GDPR Article 6(1)(f). Article 14 requires us to tell you what those interests are, and it is reasonable to expect us to show our working.

The interest. Building an accurate, comparable record of racing performance so that a sailor and their coach can see where they actually stand against a real fleet, rather than guessing. That only works if the fleet is in the data, because a result is meaningless without the people you beat and the people who beat you.

Necessity. There is no less intrusive way to do it. The results are the record. We do not enrich them with anything beyond what was published, we do not buy data, and we do not attempt to find contact details, addresses or any other information about the people in them.

The balance — the part that is genuinely arguable.

In our favour: these results were published deliberately, by the organising authority, precisely so they could be read, compared and quoted. Sailors expect their results to be public; it is how the sport works. GPS tracking services publish race replays for the same reason. We add nothing that was not already public, and we do not publish anything new — none of this corpus is on the open internet through us, none of it is indexed by search engines, and none of it appears on a page that a stranger can reach without signing in.

Against us, honestly, and this is the longer side of the ledger:

• Linking many published results into a single cross-year record about one person goes beyond what a reader of any one results page would expect. Doing it about children raises the bar further.
• Today, any signed-in SailCoach user can search the results corpus by sail number and get back a sailor's name and full race history. A sail number is painted on a hull and is short enough to guess. That is broader access than we are comfortable with. We are restricting it to a user's own records and to sailors they legitimately coach, adding rate limiting, and logging queries. None of those three exists yet, including the logging — so today nothing records that a lookup happened.
• The publishers of these results cannot see us coming. As section 5.2 says, we do not present ourselves by name, so the practical ability of an organising authority to notice us and say no is not available to them. A balance that relied on "they could block us" would be relying on something we have not built, so we are not relying on it.
• A results file can now reach the corpus because any signed-in user uploaded it or linked it, without us having chosen the source.

What the balance actually rests on, stated so it can be checked: nothing in this corpus is publicly accessible or search-engine indexed, and none of it appears on a page a stranger can reach without signing in; there is no browsable directory of sailors and no search by name for an account; we publish no league table or ranking derived from it; we never sell or license it; we add nothing that was not already published; and we honour objections without asking why. If those stop being true, the balance fails and we should be told so.

5.4 Why we have not written to you

Article 14 normally requires us to give you this notice within a month of collecting your data. We are relying on the exception in Article 14(5)(b) — that providing individual notice would involve disproportionate effort.

Here is the argument, made rather than assumed:

• We hold no contact details for any of these people. A published results row gives a name, a sail number and a club. It does not give an email address or a postal address.
• To notify you individually we would have to go and find your contact details. That would mean collecting substantially more personal data about you than we currently hold, about tens of thousands of people, most of them children — which would make the intrusion worse, not better. The ICO's guidance treats that consequence as relevant, and we think it is decisive here.
• Contacting children directly, without a parent, to tell them about a data-processing operation they have never heard of, would be the wrong thing to do even if we could.

Article 14(5)(b) does not let us simply stay quiet. It requires us to make the information publicly available instead. That is what this section is: a public, permanent, unauthenticated page at https://sailcoach.app/legal/privacy, linked from every page of our site, written to be found by someone searching for their own name alongside ours.

The limits of that argument, stated plainly:

• It excuses the notification, not the processing. If our legitimate interests balance fails, the exemption saves nothing.
• It does not apply where we do hold contact details. The moment a collected record is claimed by, or matched to, a SailCoach account, we hold a verified email address and the effort is one email — so the disproportionate-effort argument lapses for that person and we owe them the notice itself, not merely a page they could go and read. We do not yet send that email. Building it is outstanding work; until it is sending, we match a collected record to an account only where the person has claimed it themselves.
• It is a judgement, and a regulator could disagree with it. We would rather record the judgement and be argued with than not record it.

5.5 What you can do about it

If you are, or your child is, in this data:

• Write to [email protected]. Give us a name and a sail number. Within five working days we will tell you what we hold, and within one month we will give you a full copy.
• You can object. Under Article 21 you can object to processing based on legitimate interests. For this corpus, we will not ask you to justify the objection or argue "compelling legitimate grounds" back at you. We will remove the records and keep a written record of the removal, and re-apply it after each collection run. We do not have a technical suppression list, so that re-application is done by hand and by a person. If you ever see yourself back in the data, tell us — that is our failure, not your inconvenience.
• You can have it erased. Article 17 applies, and where you have objected under Article 21 and we do not have overriding grounds, erasure follows.
• You can ask us to correct it. Results data is frequently wrong — names misspelled, sail numbers shared between two sailors, the wrong person credited with a result. Tell us and we will fix it.
• You can complain to the Information Commissioner's Office. Section 14 has the address.

These rights apply equally to people who have never used SailCoach and never intend to.

6. Why we use your data, and our lawful basis

Where we rely on legitimate interests, you can object. Write to [email protected]. For anything based on consent, you can withdraw it at any time, and withdrawing it does not make what we did before unlawful.

Do you have to give us this data? Your name and email address are needed to have an account — without them there is no account. Your date of birth is needed so we know whether to apply parental oversight; if you do not give it we treat you as a minor. Everything else is optional, and the product works without it.

7. Who we share it with

We do not sell personal data. We do not share it for advertising. Here is the complete list of who else sees it.

7.1 Coaches you connect with

A coach you connect with can see your profile, your sessions with them, notes and feedback they write about you, and whatever data types you have agreed to share. A coach who is merely connected to you cannot see your medical notes, emergency contact, date of birth, phone number or the parent email on your record. Those are stripped out.

7.2 Parents and guardians — read-parity, precisely

If you are under 18 and a parent or guardian is linked to your account, they can read what you can read. That means your profile, including your medical notes and emergency contact; coach notes about you, including private ones, and they can reply and react to them; your sessions; your feedback; and your message history.

What a parent cannot do:

• They can never speak as you in a conversation. A parent has no ability to send a message in your name. That is refused unconditionally, for every parent, in every circumstance, before anything else is checked.
• They cannot write your reflections once the account is yours. If a parent created the account and still runs it for you, they can — they are the sole operator of it. From the moment you set your own password, reflections are yours alone and the app refuses it.
• They cannot see anything about you once you turn 18. Read-parity ends automatically on your eighteenth birthday. The link stays so they can still see you listed, but the access is gone. Nobody has to remember to switch it off.

At most two guardians can be linked to a child. Links are only ever created by an emailed invitation, never by a shareable link, because a URL is too much authority to hand to whoever happens to hold it. Invitations are only written by our servers, never taken from whatever a browser sends us.

One gap you should know about. Your date of birth is what drives all of this, and at the moment a sailor can edit their own date of birth. A young sailor who changes their date of birth to make themselves an adult switches off their parent's access in a single step, and the parent is not told. We are fixing this by requiring a guardian or administrator to change a minor's date of birth and notifying the guardian when it changes. Until then, a parent who finds they have lost access should contact [email protected].

7.3 Club administrators

An administrator of your club can see, for every sailor in that club:

• Your profile in full, including your medical notes, emergency contact, date of birth and phone number.
• Squad membership, attendance, availability and grading history.
• Reported messages. Where a message is reported, a club administrator can read that message's content so it can be assessed. That includes private messages involving children. Coaches are not moderators and do not get this access; it sits with club and platform administrators only. Every action is logged.

This is a real concentration of sensitive information in one role. We think it is the right design — somebody at a club has to be able to see who has asthma before they go afloat — but we should be straight about two things: there is no vetting requirement attached to the club administrator role in the product today, and parents are not routinely shown who at their club holds it. Both are on our list. In the meantime, ask your club who its administrators are; they should be able to tell you.

7.4 Other sailors

Other sailors see very little about you. There is no browsable directory of sailors in SailCoach, deliberately, because most sailors are children — the only people-search for an account is by exact email address or phone number, and a name will not find anybody. Other sailors in a shared session can see that you were there. If you share a note or a photo with someone, they see it.

Two exceptions, and the second is the one we are least happy with.

• Race results and fleet analysis are inherently about a fleet: your finishing position in a race is visible to anyone who can see that race, because that is what a race result is.
• Anyone with a SailCoach account can type a sail number into the results lookup and get back the names attached to it and the race history behind them — including yours, and including a child they have no connection to. They get no notes, no messages and nothing a coach wrote. They do get where you sailed and how you did. Sail numbers are short and guessable, so this is a discovery surface, not a coincidence. Section 5.3 sets out what we are doing about it.

7.5 Companies that process data for us

We use third-party services to host, send email, monitor errors and analyse coaching text. Every one of them is listed — with what they receive, what they do with it and where they are — in our Subprocessor List. That page is the authoritative version and we update it when it changes.

Two that deserve a mention here because of what they see:

• Our AI provider, Anthropic, receives free-text coaching commentary and voice-note transcripts. No sailor is named to it on any path, and coaches appear only as "Coach 1", "Coach 2". Section 8.
• Our error-monitoring provider, Sentry, receives error reports with your email address and user ID attached. It also records a replay of the screen for a sample of sessions and for every session where an error occurs — but only if you have accepted the analytics category, and with all text masked and all media blocked before the recording leaves your browser, so a replay shows layout and interaction rather than the content of anyone's notes. Before this release those replays captured on-screen text unmasked; that was a defect and it is fixed. Whether replay should run on signed-in pages at all is a question we have not settled, and it is on the DPIA register with a date. The Cookie and Storage Notice has the detail.

7.6 Anyone else

• If you tell us to. For example, when you accept a connection or share data with a coach.
• Where the law requires it. A court order, a statutory request, or a lawful request from a law-enforcement or regulatory body. We check that a request is valid before we act on it.
• Where a child may be at risk of harm. We will share information with a club welfare officer, a local authority designated officer, the police or the RYA where we believe it is necessary to protect a child. We will not tell the person concerned first if doing so might increase the risk. This is set out in our Safeguarding Policy.
• If the business changes hands. If Innovology Ltd is sold or merged, data may transfer to the new owner, who would be bound by this policy until they lawfully told you otherwise. We would tell you before it happened.

8. AI and automated analysis

Our full position is in the AI and Automated Decisions Statement. In summary:

8.1 What actually goes to an AI provider

We use one AI provider: Anthropic, in the United States, running a Claude model. It is used for five things:

1. Summarising a single piece of coach feedback, and classifying its sentiment and key points.
2. Summarising a sailor's whole feedback history into themes and recommendations.
3. Suggesting drills based on recent feedback.
4. Producing group-level insights from a session's feedback.
5. Tidying a spoken note into an organised written note.

No sailor is named to Anthropic on any path. Every prompt refers to "the sailor" and instructs the model never to invent or guess a name. On path 2, coaches are replaced with "Coach 1", "Coach 2" and so on before the text is built, so a theme that recurs across coaches is still visible without naming anybody. Path 5 sends the transcript and nothing else. What does leave us is the coaching prose itself, which is still personal data about an identified child even with the name taken out — prose about one person does not stop being about them — which is why it is covered by section 9.

On path 4, names are additionally stripped from the body of the text before it leaves us. We will not call that anonymisation. It removes the names we already know about, plus capitalised words in the possessive form such as "Sam's" — a name used in any other position is not caught. It is pseudonymisation: it reduces risk, it does not eliminate it.

Anthropic's commercial API terms are that inputs and outputs are not used to train their models. We rely on those terms. A data processing agreement with Anthropic and a documented transfer mechanism are outstanding items; see section 9.

If you would rather no AI processing happened at all, tell us at [email protected]. Every AI feature in SailCoach fails soft — the product works fully without it — so this is a request we can actually honour.

8.2 Voice notes go to Google before they go to us

If you dictate a note, we use your browser's built-in speech recognition. On Chrome and Chrome-based browsers, that is not processed on your device: the audio is sent to Google's servers, transcribed there, and the text handed back to the page. The transcript is then sent to Anthropic to be tidied, and saved to your notes.

So a spoken note by a child involves the child's voice reaching Google and the transcript reaching Anthropic. We had this documented internally as "no upload", which was wrong, and correcting it is one reason this policy exists. If you do not want that, type the note instead — the same feature works from typed text, and on Safari and Firefox the speech feature is either on-device or unavailable.

8.3 The Helm Grade and the headroom verdict are not AI

The Helm Grade is a published Bayesian rating algorithm — the same family of maths used to rate chess and online games — replayed over race results. The headroom verdict ("Ready for bigger fleets", and similar) is four fixed thresholds tested against that rating. The race analysis and the written race reflection are geometry over GPS data with the sentences filled in from templates.

None of it is AI, none of it learns from your data, and all of it is reproducible from the underlying race results. We describe it as statistical analysis and we will not badge it as AI. Nothing in the product is badged "AI" unless it genuinely calls our AI provider: two features that were previously mislabelled have been renamed, and the animation that made a templated summary look like a model working now appears only over a real model call.

8.4 Automated decisions

We make no decisions about you by automated means alone that produce legal effects or similarly significantly affect you. Nothing in SailCoach automatically selects a squad, picks a team, awards or removes a grading level, or enters anyone for an event. Grading levels are set by a human coach and confirmed by a human. Access to data is decided by who you are and what you have agreed to share, never by a score.

The headroom verdict is advice to a human. We ask clubs and coaches not to treat it as a decision: the Helm Grade and the headroom verdict must not be the sole basis for squad selection, team selection or event entry. The four tests behind a verdict are published in the AI and Automated Decisions Statement, and where a verdict says "ready" the product lists the actual races it rests on. It does not yet display the four tests next to the verdict, and the underlying workings are shown only on an adult sailor's page — so on a child's page a coach cannot currently see the arithmetic they are being asked to interrogate. Adding both is outstanding work. Ask us at [email protected] in the meantime and we will show you the working for any verdict.

If you think an automated output has been used to make a real decision about you, tell us at [email protected] and we will look into it.

9. Sending data outside the UK

The honest position: the centre of gravity of our infrastructure is the United States.

Our hosting provider, our object storage, our error monitoring, our email provider, our AI provider and Google sign-in are all United States companies, and nothing in our configuration pins them to a UK or EU region. Our map tiles come from the OpenStreetMap Foundation, a UK charity, and our weather and geocoding lookups go to Open-Meteo, but we have not verified where either is hosted and we will not claim a UK or EU location we have not confirmed.

Transfers out of the UK need a legal mechanism under UK GDPR Articles 44 to 49 — normally the UK International Data Transfer Agreement, or the EU Standard Contractual Clauses with the UK Addendum, plus an assessment of the risk in the destination country.

Where we stand, provider by provider, rather than asserting blanket coverage:

We are not going to write "appropriate safeguards are in place" over the top of that. This is a live piece of work and the Subprocessor List is updated as each one is completed. If you want the current state of any specific one, ask at [email protected] and we will tell you.

10. How we protect your data

What we actually do:

• Everything travels over HTTPS. No personal data moves between your browser and us in the clear.
• Passwords are hashed, never stored. The minimum password length is ten characters, set deliberately higher than the usual default because this is a platform holding children's data. Signing out or resetting a password revokes existing sessions. Sign-in sessions expire after seven days without use; a session that is used keeps rolling forward, so there is no fixed maximum lifetime.
• Photos and video live in a private bucket. Nothing is publicly readable, and media is served through short-lived signed links — one hour for video and note attachments, four hours for photos. A link is minted only after we have checked your access to the record the file belongs to, such as the note, the session or the event. Separately, the server refuses to store a file reference that does not sit under the uploader's own prefix, which blocks the common attack where somebody borrows another person's file reference and gets a working link back. File types that could carry an attack are refused on upload.
• Every route in the main API protects itself. There is no single gate on it that can be left open: each part checks permissions for itself, an automated check fails the build if a route ships with no visible authorisation, and a second check verifies that every media route enforces ownership. Both of those checks scan the main API only. Our administration console takes the opposite approach — one gate applied to its whole surface — and it, the authentication service and the club service are not yet covered by either automated check. Extending them is outstanding work.
• Sensitive fields are stripped, not just hidden. Medical notes, emergency contacts, dates of birth and phone numbers are removed from the data before it is sent to a viewer who should not see them, rather than being sent and hidden in the interface.
• Message sends are logged. Every message sent is recorded with the sender, the time, the IP address and the browser. A report is recorded with the reporter and the time, but not the IP address — which is the wrong way round, and we are fixing it. Messages cannot be edited or deleted, so once sent, a message stays.

What we do not claim:

• We do not have a general security audit trail. One class of action is recorded today: when a parent acts on behalf of their child, we log the parent, the action, the child, the time and the IP address. Sign-ins, failed sign-ins, password changes, permission denials and role changes are not logged. The code to write those records exists and nothing calls it. Wiring up the rest of the trail is outstanding work, and until it is done we cannot reconstruct an authentication incident from our own records.
• We do not claim data is encrypted at rest. Our hosting provider may encrypt its storage, but we have not verified it and we will not assert it.
• We hold no security certifications. We are not ISO 27001 certified, not Cyber Essentials certified, and not SOC 2 audited.
• Backups are currently taken manually rather than on an automated schedule, and there is no point-in-time recovery. That is a resilience weakness, we know it, and automated backups are a priority piece of work.

No system is perfectly secure. If you find a vulnerability, please tell us at [email protected] — we will take it seriously and we will not pursue anyone who reports one in good faith. Our approach is set out in our Security Policy.

11. How long we keep your data

The full schedule is in the Data Retention Schedule, and it distinguishes between periods that are enforced automatically and periods we operate by hand. The honest headline is that almost all of them are by hand.

In summary:

• Your account and its content are kept while your account exists. When you ask us to delete your account, we delete the account record — which ends sign-in immediately, because we have no way to suspend an account short of deleting it — and then work through every other store by hand. Deleting the account record does not cascade: your notes, messages, sessions, training records, goals, reflections, media and analytics events each have to be found and removed separately. That hand-work is why closure takes days rather than seconds, and it is why we tell you specifically what we removed.
• Sign-in sessions expire after seven days of disuse, automatically. This is the one retention rule that is genuinely enforced by the system.
• GPS race tracks and race results currently have no automatic expiry. They are kept as a durable record so that analysis can be rebuilt. Section 5 explains how to have your own removed.
• Messages cannot be deleted or edited by anyone using the product. A moderator can withdraw one, and that marks it hidden rather than erasing it, so a safeguarding concern can still be investigated. The retention schedule sets out how long.
• Analytics and audit records are covered in the retention schedule. We are not going to quote a number here, because our own audit found that a retention rule we believed was running may never have been applied to the live data. Rather than repeat a figure we cannot stand behind, the schedule states what we have verified and what we have not.

The most important thing to be honest about: we do not yet have a deletion routine that reaches every collection and every stored file, and there is no "delete my account" button. Deletion today is done by us, by hand, when you ask, and we cannot yet promise we have found everything — so we tell you what we removed and what we could not. Building a cascading delete, self-service deletion and a working data export is the single largest piece of outstanding work on this list, and until it ships, [email protected] is how you exercise these rights. We will not hold your request up because the button does not exist.

12. Children and young people

Most people using SailCoach are children. There is a version of this policy written for sailors themselves at Privacy for Young Sailors, and our commitments under the ICO's Age Appropriate Design Code are at Our Children's Code Commitments.

12.1 What actually protects a young sailor today

• If we do not know your age, we treat you as a child. A missing or invalid date of birth means parental oversight applies, not that it does not.
• A parent or guardian can be linked to a child's account and reads what the child reads, until the child turns eighteen. Section 7.2.
• A parent can act for their child on their profile, on scheduling, on consenting to a connection and on entering data — but never to send a message in their child's name. That one is refused for every parent in every circumstance. On an account the parent created and still runs, they can also write the child's reflection; on an account the child owns, they cannot.
• Guardian links are made by email invitation only, never by a shareable link, and at most two guardians can hold one.
• Sensitive fields are not visible to a coach who is merely connected. A squad medical note is readable by the squad's coaches, which is wider than it should be — section 3 says so plainly.
• No child is ever named on a public page. A coach's public profile never names the sailors they coach. There is no public list of sailors, there is no way to browse for a child, and our site instructs search engines to stay out of every signed-in area. The sail-number lookup in section 7.4 is the exception, and it is signed-in only.
• Under-13s get extra restrictions. Weight records for a sailor under 13 can only be recorded by a parent, and competitive "rival" framing is switched off entirely for under-13s.
• Every message sent is logged with the sender, the time, the IP address and the device. Messages cannot be edited or deleted, so the record cannot be tidied up afterwards. This is the strongest of the controls on this list.

Two things on that list are weaker than a reader would assume, so we are stating them here rather than leaving them to be found:

• Messages are checked against a short list of abusive words. That check does not detect grooming. We have written a scanner that looks for contact-detail exchange, requests to move to another app and secrecy language, and it is not yet connected to the sending of messages — the date we will connect it by is in our Safeguarding Policy. Nobody should rely on the automatic check as though it watched for grooming.
• Reporting a message does not alert anyone. The report is recorded and the message is flagged, but no notification fires and no screen displays the queue; it is read when we go looking. If something worries you, email [email protected] as well. That mailbox is read by a person.

12.2 What we do not do, and will not pretend to

We do not obtain verified parental consent before a child uses SailCoach. Our previous privacy page said we did. It was wrong, and correcting it is the reason this policy was rewritten.

What actually happens today:

• When a child registers, our signup form asks for a date of birth and, if they are under 18, for a parent or guardian's email address. Those are checks in the web page, not in the server. A signup that bypasses the web page is not stopped.
• The parent email a child gives us is an unverified hint. We do not email that parent. It is only ever used later, if that same person independently registers and verifies the address, to offer them a link to their child.
• We do not verify anyone's age, in either direction. An adult can register as a child and a child as an adult.
• We do not check who is typing when health information is entered. Section 3 says only a parent can give explicit consent for a sailor under 13; the form does not enforce that, so we cannot prove a medical note on an under-13's profile came from their parent.
• We do not obtain parental consent for photographs or video of a child. Access to that media is tightly controlled; consent to it existing is not collected. Our Image Use Policy sets out what we ask clubs and coaches to do in the meantime.
• A same-club adult can currently start a direct conversation with a child without a connection, without parental approval and without the parent being notified. This began as a way to run club and emergency broadcast threads and is too broad; we are restricting it to those thread types.
• We do not notify a parent when a connection request is made to their child, when a new adult messages their child, or when their child's date of birth changes. Parental oversight is currently something a parent has to go and look at, not something that comes to them.

12.3 What we are doing about it

In priority order, and stated so you can hold us to it: verify the parent's email address at signup and require a parent to activate a self-managed under-16 account before that child can connect or message; stop a minor from changing their own date of birth; notify guardians of connection requests, first contact from a new adult, and date-of-birth changes; enforce date of birth at the server rather than in the browser; and add per-child image consent held by the guardian.

Our rule in the meantime: a child under 13 should only use SailCoach through an account a parent set up and manages. We cannot enforce that technically today, and we are not going to claim otherwise.

If you are a parent and you want to know what we hold about your child, or you want it deleted, write to [email protected]. We will not make you prove a technical case; we will ask enough to be satisfied you are the parent, and then we will do it.

13. Your rights

You have the following rights over your personal data. They apply whether or not you have an account with us.

How to use them: email [email protected]. We will acknowledge within five working days and respond in full within one month. If a request is genuinely complex we may extend by up to two further months, and we will tell you why within the first month. We do not charge.

We may ask you to confirm who you are before we hand over data — proportionately, and not as an obstacle. For a request about a child, we will ask enough to be satisfied you are their parent or guardian.

Your Data Rights explains each right in more detail and what to expect at each step.

The honest caveat: we do not yet have self-service export or deletion. Everything above is done by hand, by a person, when you ask. That is slower than a button but it is not a reason to say no, and the statutory deadlines apply to us regardless.

14. Complaining

If you are unhappy with how we have handled your data, tell us first at [email protected] — that is the mailbox that can actually fix it. If you want it handled as a formal complaint with a written outcome, use [email protected] and our Complaints Procedure, which sets out what happens next and by when.

You do not have to come to us first. You can complain directly to the UK's data protection regulator at any time:

Information Commissioner's Office Wycliffe House, Water Lane, Wilmslow, Cheshire SK9 5AF Helpline: 0303 123 1113 ico.org.uk/make-a-complaint

You can also take a claim to court.

15. Cookies and what we store on your device

We use a sign-in cookie, and — if you agree to them — an identifier used for analytics and a masked session-replay recording from our error-monitoring provider.

Every cookie and storage key, what it is for, how long it lasts and whether it is strictly necessary, is listed in the Cookie and Storage Notice.

The position: PECR regulation 6 requires your consent before anything non-essential is stored on your device, with refusing as easy as accepting. We ask before we store. The banner offers "Reject all" and "Accept all" with identical prominence and a "Choose" option between them; nothing in an optional category is written before you answer; pressing Escape counts as a refusal; and if your browser sends a Global Privacy Control signal we treat that as a refusal of both categories and do not ask at all.

There are two optional categories — preferences, and analytics (which also covers the masked session replay). You can change your answer at any time from the panel on the Cookie and Storage Notice. Withdrawing analytics consent deletes the identifier and the other analytics keys from your browser straight away, and so does signing out. The one thing we cannot make instant is a replay already in progress: the recorder cannot be detached mid-page, so it stops at your next page load.

Two things are stored whatever you decide, because they are the thing you asked for rather than something extra we wanted: the sign-in session, and your light or dark theme choice.

16. If you are not in the UK

Our primary regime is the UK GDPR and the Data Protection Act 2018. We have users elsewhere, and other rules may apply to you as well.

European Union. The EU GDPR gives you substantially the same rights as those in section 13, and you can complain to the supervisory authority in your country of residence, work, or where the issue happened. We have not yet appointed a representative in the EU under Article 27, and we do need one — section 1 explains why the exemption is not open to us. It is an overdue step, not an open question. Until it is done, write to [email protected].

California, United States. If the CCPA as amended applies to you, you have rights to know what we collect, to have it deleted, to correct it, and to opt out of the sale or sharing of your personal information. We do not sell personal information and we do not share it for cross-context behavioural advertising, so there is nothing to opt out of. We do not offer financial incentives for data and we will not discriminate against you for exercising a right.

Children in the United States. COPPA requires verifiable parental consent before an operator collects personal information from a child under 13, and it bites as soon as the operator knows a user is under 13. We do know: we accept a date of birth from age five and we change what the product does for under-13s. We do not operate a verifiable parental consent mechanism, so any US under-13 account is being run without one, and we are not going to describe that as compliant. What we are doing about it: identifying every account with a US-resident under-13 sailor, writing to the parent address on the record, and either obtaining consent through an approved method or closing the account and deleting its data. A parent in the US can at any time write to [email protected] to review everything we hold about their under-13 child, refuse any further collection, and have it all deleted, and we will do that without asking for a reason. Until the mechanism exists, a child under 13 in the United States should not create an account.

Canada. PIPEDA works differently from UK law in a way that matters here: it requires your knowledge and consent, and it has no equivalent of the legitimate-interests basis we rely on in section 5. The exemption for publicly available information is defined by regulation and covers directories, public registries, court records and publications you supplied information to — not results pages collected from a club or class website. We therefore cannot claim a PIPEDA basis for holding a Canadian sailor's collected race record. If you are in Canada and you are in that corpus, write to [email protected] and we will remove you; we will not ask you to justify it. You can also request access to anything we hold, challenge our handling of it, and complain to the Office of the Privacy Commissioner of Canada.

Australia. Under the Privacy Act 1988 and the Australian Privacy Principles you can request access and correction, and complain to the Office of the Australian Information Commissioner.

Whichever applies, the fastest route is the same: [email protected].

17. Changes to this policy

This is version 1.0.0, effective 17 September 2026.

Every version of this policy stays published at its own permanent web address. When we replace it, the old version does not disappear — you can always go back and read the version that applied when something happened, and see a summary of what changed between them.

If we make a material change — a new purpose, a new category of data, a new lawful basis, a new recipient, or anything that reduces your rights — we will tell registered users by email or in the product before it takes effect, and we will not apply it retroactively to processing that has already happened.

Small corrections — a broken link, a clearer sentence, a subprocessor's name changing — will be published as a new version with a note saying what changed, but we will not email you about them.

If you disagree with a change, you can object, withdraw any consent you gave, or ask us to delete your account. Write to [email protected].