Data Protection Impact Assessment

What this document is

This is the published summary of the data protection impact assessment we carry out for SailCoach under Article 35 of the UK GDPR.

Innovology Ltd, trading as SailCoach, is the controller for the processing described here. Innovology Ltd is registered in England and Wales.

A DPIA is a working document, not a certificate. Ours is built on a line-by-line review of the code that actually runs the platform, rather than on a description of how the product is meant to work. Where the review found a control we thought we had and did not, that is written down here as a risk with a date against it. Several of the entries in the risk register below are unresolved, and they are named rather than summarised away.

The full internal assessment records endpoint-level detail that would be unsafe to publish. This summary carries everything that matters to a sailor, a parent, a club or a regulator: what we do, why it is lawful, what could go wrong, what we have built to stop it, and what is still outstanding.

Why a DPIA is required

Article 35(1) requires a DPIA where processing is likely to result in a high risk to people's rights and freedoms. The ICO publishes a screening list; two or more criteria normally mean a DPIA is mandatory. We trip eight of the ten.

ICO criterion	Us?	Why
Innovative technology	Yes	We capture GPS race tracks by driving a headless browser over public race-replay viewers, and we send some coaching text to a large language model.
Denial of service	No	Nothing on the platform decides whether someone gets access to a service, opportunity or benefit.
Large-scale profiling	Yes	We build a per-person skill rating and per-race performance metrics for everyone in an ingested fleet, not only for our own users.
Biometric data	No	We hold no biometric data. Video of sailors is coaching footage; nothing measures or matches a face or a body.
Genetic data	No	None.
Data matching	Yes	We cluster names across sail numbers and events to build a single person record, and we stitch pre-signup browsing to an account after registration.
Invisible processing	Yes	A large part of what we hold comes from published results pages, not from the person. They did not give it to us and mostly do not know we have it.
Tracking	Yes	Precise position, heading and speed for a named individual, and behavioural analytics across the website.
Targeting children	Yes	Junior sailing is the core use case. The service is directly offered to children, profiles them, and holds welfare information about them.
Risk of physical harm	Yes	A platform that lets adults contact children privately, and that holds medical information relied on by a coach on the water, can contribute to physical harm if it fails.

Two further things make the assessment mandatory rather than advisable.

Article 35(3)(b). We process special category data — free-text medical and welfare notes about sailors, most of whom are children — and criminal offence data, in the form of coaches' DBS records. Our medical processing is not large scale in itself. The profiling limb is, and that is enough.

The Children's Code. SailCoach is an information society service likely to be accessed by children, so the ICO's Age Appropriate Design Code applies to us in full, and standard 2 of that code requires a DPIA. See Our approach to the Children's Code.

One limb we do not rely on, but should record as arguable: Article 35(3)(c) covers systematic monitoring of a publicly accessible area on a large scale. Harvesting the positions of every boat racing at a public event has some of that flavour. We do not think it is what the limb was written for, but a regulator might, and the risks it would raise are already on the register under R10.

The decisive factor is children. Everything else on this list would be manageable on its own. The combination — profiling, welfare data, private messaging, and a user base whose median age is somewhere around thirteen — is what makes this assessment necessary and what sets the standard it has to meet.

What the processing involves

The nature of the processing

SailCoach is a coaching platform for sailors and the people who coach them. The processing has four distinct parts, and they carry very different risks.

1. The coaching record. Accounts, training sessions, attendance, goals, coach notes about a sailor, a sailor's own notes, session feedback and ratings, skill assessments, squad membership and grading, photos and video of sailors with coaching annotations drawn over them, direct messages, and welfare information: a medical or welfare note on a profile, a separate medical note on a squad member, an emergency contact, and — optionally — a body weight.

2. Race data. Results and GPS tracks, both for our own users and for whole fleets. A track is a timestamped sequence of position, heading and speed for every boat in a race, attributable by sail number to a named person. From that we derive start position, speeds, distances, places gained on each leg and penalties.

3. Analysis. A Bayesian skill rating per sailor per boat class, a "headroom" judgement that tells a sailor whether they have outgrown their fleet, and various deterministic performance breakdowns. One feature sends coaching text to a language model. Most of what looks like analysis is ordinary statistics, described in full in How we use automated analysis and AI.

4. Running the site. Authentication, transactional email, error monitoring, and first-party product analytics.

Data lives in a MongoDB database, a Redis cache and queue, and a private object-storage bucket, all hosted on Railway. Roughly sixty collections are in live use. Who else processes your data lists every third party and what each one receives.

The scope

We do not publish user numbers in this document; the platform is young and small, and a headline figure would be the least useful number here. The figures that matter to the risk assessment are these.

Age. A date of birth is accepted from age 5. The adult threshold is 18. Optimist-class racing — the single largest slice of the race data — is sailed by children roughly aged 8 to 15.
Guardianship. A child account can have at most two guardians. Links are written only by the server, never from a request body.
Sources. Six external results and tracking sources are crawled, most of them daily, and the Internet Archive is used to recover result files that have since been deleted from the original sites. The design target recorded in the repository is over 200 events, thousands of sailors and more than 50,000 boat tracks.
Free text. There are more than fifteen unbounded free-text fields attached to an identified sailor. Nothing constrains what a coach types into them.
Behavioural analytics. Page views, page exits with time-on-page, clicks, form submissions and the full query string, stored with the full IP address and user agent — collected only from visitors who have accepted the analytics category.
Error monitoring. Error and performance reporting runs for everyone. Session replay runs only for a visitor who has accepted analytics, and then records 10% of sessions and 100% of sessions in which an error occurs, with all text masked and all media blocked before the recording leaves the browser.
Message safety. Automated content checking on messages is a seven-word profanity list. That is the whole of it.
AI. One provider, one model, five functions, in two files. With the API key removed the product is fully functional and entirely deterministic.
Payments. None. There is no payment provider in the platform, and we hold no card or bank data.

The context

Three relationships run through everything here, and each one contains a power imbalance over a child.

Coach and sailor. A coach writes an assessment of a child, sees their welfare note, can message them privately, and can record a judgement that shapes what squad they sail in. A twelve-year-old is not in a position to object to any of that, and a parent who did object would be asking their child's coach to treat them differently. Consent is therefore the wrong lawful basis for most of the coaching record — it would not be freely given — and we have not used it there.

Parent and child. A parent can create a child's account, and a guardian can read what their minor child can read. That is proper oversight, and it is also an intrusion into a teenager's private space. We have drawn the line at reading, never speaking: a parent can never post, message or reflect as their child.

Club and member. A club administrator can see the medical notes, emergency contacts, dates of birth and phone numbers of every minor at their club, and can read reported private messages. That is an appropriate capability for the role. There is at present no vetting requirement attached to holding it, which is on the register as R9.

Our users are mostly in the UK. There are real signups in the EU, the US, Canada and Australia. UK GDPR and PECR are the spine of this assessment; EU GDPR and the EU AI Act apply to the EU users; US, Canadian and Australian law are live considerations we keep under review. We have not appointed an EU Article 27 representative. The exemption in Article 27(2) is for processing that is occasional, involves no large-scale special category data and is unlikely to risk people's rights, and on the assessment set out in this document ours is none of those three. So this is an overdue step rather than an open question, and it is R17.

The largest single body of personal data we hold is about people who never signed up. Published race results name the helm and often the crew, with their club, nationality, age group and every score and penalty. We harvest those pages, extract the rows, link them across events by sail number, cluster the names into person records, and compute performance metrics and ratings for the whole fleet. Most of those people are children. None of them gave us anything. This is Article 14 processing and it is the part of SailCoach that a regulator would look at first. It is treated on its own terms below and at R10.

The purposes

Purpose	Why we do it
Run coaching accounts and sessions	To deliver the service a sailor, parent or coach signed up for.
Hold coach notes, feedback and assessments	Coaching only works if last month's session is still there this month.
Hold welfare and medical notes	So the coach taking a child on the water knows what they need to know to keep them safe.
Hold coach qualification and DBS records	So a club can see who is vetted and current, and so lapses are visible.
Squad organisation, grouping and safety limits	To run a session with the right ratios and the right people ashore.
Race results and GPS analysis	To show a sailor what actually happened in a race rather than what they remember.
Skill rating and headroom judgement	To give an honest read of where a sailor stands, with uncertainty shown.
Messaging	Coach-to-sailor and club communication.
Content moderation and audit logging	Safeguarding, and being able to reconstruct what happened.
Error monitoring	To find and fix faults.
Product analytics	To see which parts of the product are used and where people get stuck.
Transactional email	Verification, invitations, notifications.

Consultation

We are recording this honestly, because a consultation section that lists meetings that did not happen is worse than an empty one.

Who has been consulted. This assessment was produced from a full technical review of the platform, commissioned for the purpose and carried out against the source code rather than against documentation. Every finding in the register below is anchored to something that is actually in the system. No outside party has been consulted, and no group of users has been asked for their view.

Who has not been consulted, and when they will be. Before the first review of this document we will consult three groups:

Coaches and club volunteers, on adult-to-child contact, on what vetting should be required to hold a club administrator role, and on what they need medical notes for — by 31 March 2027.
Parents and guardians, on notification: what they expect to be told when an adult contacts their child, and what they would consider surveillance of their own child rather than oversight — by 31 March 2027.
Young sailors themselves, in an age-appropriate way, on what they think their coach and their parent should be able to see — by 30 June 2027. Standard 2 of the Children's Code expects children's views to be taken into account, and a policy about children written entirely by adults is exactly what that standard is aimed at.

The ICO has not been consulted. Article 36 requires prior consultation where a DPIA indicates that the processing would result in a high risk in the absence of measures taken to mitigate it. Three risks on our register (R1, R2, R3) are rated high after the mitigations that exist today. Our conclusion is not that those risks should be accepted and consulted on, but that they must be removed, and each carries a dated commitment below. We will re-rate all three on 31 December 2026. If any of them is still rated high on that date, we will switch the capability off rather than keep running it, and we will consult the ICO before switching it back on.

There is no data protection officer. We are not a public authority. Our special category and criminal offence processing is small in volume and incidental to the service, rather than a core activity. The limb of Article 37 that gives us most pause is regular and systematic monitoring on a large scale, which is arguable given the race-data corpus; we have concluded we are below the threshold, and we keep that conclusion under review at each revision of this document. Accountability for data protection sits with the director of Innovology Ltd, who signs this assessment off. If you want to raise something, [email protected] reaches that person directly.

Necessity and proportionality

Lawful bases

Processing	Article 6 basis	Article 9 / 10 condition
Accounts, sessions, coaching records, messaging, notes	Contract — it is the service you asked for	—
Records about children on a club list who have no account	Legitimate interests: running junior training safely, balanced against the child's interests	—
Medical and welfare notes	Legitimate interests — keeping a sailor safe on the water, balanced against the sailor's interests. We do not use consent as the Article 6 basis, for the reason set out below the table	Art. 9(2)(a) explicit consent where the sailor or guardian gives the information — given by a parent or guardian where the sailor is under 13; Art. 9(2)(g) with DPA 2018 Sch. 1 Pt 2 para 18 (safeguarding of children) where it is held for protection; Art. 9(2)(c) vital interests in an on-water emergency
Coach DBS and safeguarding records	Legitimate interests — parents and clubs are entitled to know whether an adult coaching children has been checked. We are not under a legal obligation to hold these records; the duty to check sits with the club arranging the activity	Art. 10 with DPA 2018 Sch. 1 Pt 3 para 29 (consent). A coach chooses to record and upload their own certificate and can withdraw it. We do not rely on the safeguarding condition in Part 2 paragraph 18 here, because that condition is only open to us where the processing is carried out without the data subject's consent, and this processing is not
Race results and GPS harvested from public sources	Legitimate interests — see the balancing test below	—
Skill rating and headroom judgement	Legitimate interests	—
AI analysis of coaching feedback	Legitimate interests; the feature is off entirely where the key is not configured	—
Content moderation, audit logs, security logs	Legitimate interests, and Art. 6(1)(c) where a safeguarding duty bites	Art. 9(2)(g) with Sch. 1 Pt 2 para 18 where a concern is recorded
Error monitoring	Legitimate interests	—
Analytics and non-essential storage	Consent (PECR reg. 6 and Art. 6(1)(a))	—
Transactional email	Contract	—

Two notes on this table.

We have deliberately not put consent against things we do anyway. A coach's notes about a sailor are not consent-based, because withdrawing that consent while continuing to be coached is not a real option. The same reasoning is why the Article 6 basis for a medical note is legitimate interests and not consent: a sailor cannot realistically refuse a club that asks for one and still sail, so that consent would not be freely given. We do need explicit consent under Article 9, because no other condition is open to us — so the note is genuinely optional, nothing stops working without it, and deleting it removes it. Conversely, analytics and session replay are consent-based, because PECR requires it and legitimate interests is not available for them.

Where we rely on a DPA 2018 Schedule 1 Part 2 condition, the 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 our retention and erasure policy for that data. Publishing this assessment alongside the Safeguarding Policy and the Data Retention Schedule covers much of that ground, but none of the three was written for the purpose and together they do not yet meet paragraph 5(2) of Part 4. Until the document exists, our reliance on the safeguarding condition is not secure. Completing it is an open action, listed in the outcome below.

The balancing test for harvested race data

Results are published by event organisers and clubs on the open web, precisely so that they can be read. Our purposes — letting a sailor see their own record, and giving fleet context to a race analysis — are compatible with the reason the data was published. We do not sell it, use it for advertising, or make it browsable: there is no index of sailors anywhere in the product, every route that serves the corpus requires a signed-in account, and no sailor's name appears on any page a search engine can reach.

Against that: the people concerned are largely children, we combine records across events into a single person record in a way the original publisher did not, we derive new information about them (speeds, ratings, judgements), and we keep it indefinitely. A child who came 40th at a club open in 2014 would not expect that row to be sitting in a dossier keyed to their name a decade later.

We consider legitimate interests holds for the purposes stated, and does not hold for anything wider. Article 14 requires that we tell those people. We have relied so far on the disproportionate-effort exemption in Article 14(5)(b) — we hold no contact details for them and could not reach them individually without acquiring a great deal more personal data than we have. That exemption is only available where we instead make the information publicly available, and until now we did not. Our Privacy Policy now carries a section written for people who are in the results corpus and are not users, explaining what we hold, where it came from, and how to object or have it removed. Building the suppression list that makes removal reliable is R10 and is dated.

Minimisation, and the design decisions that reduce risk

These are controls that exist in the running system today.

Oversight fails closed. If a date of birth is missing or unreadable, the account is treated as a minor everywhere. The failure mode is more protection, not less.
A parent can never speak as their child. Guardian authority covers profile, scheduling, data entry and consenting to connections. Posting, messaging or reflecting as the child is refused unconditionally, for every guardian, in every case.
Guardian oversight ends automatically at 18 and grants no data access after that, without anyone having to remember to switch it off.
Guardian invitations are email-only. There is deliberately no shareable link, because a link is too much authority to hand to whoever happens to hold the URL. A child can have at most two guardians.
A squad medical note is never on a list. Every list view shows a boolean — this sailor has a note — and never the text, and the day view shows the words only to the coach running that sailor's group. There is no CSV, no PDF, no print view and no email path for it: the text leaves the server only as data to an authorised coach's browser. The limit of this control, stated because it is narrower than it reads: any coach listed on the squad can open any member's page and read their note on any day, whether or not they are running that group. Narrowing it to the coach on the day is on the register at R9.
A bare connection does not unlock welfare data. A connected coach or peer sees profile detail but not medical notes, emergency contacts, date of birth, phone number or parent email. That separation was built to fix a real defect.
Sailors are never named on a public coach page. A coach's public profile is a whitelist projection that cannot identify the children they coach, and nothing is public at all until the coach chooses it.
The club verifies a coach's qualifications; the coach cannot verify their own. DBS and safeguarding are first-class credential types with issuer, reference and expiry. Editing the substance of a credential voids its verification, so nothing can be verified and then quietly swapped.
There is no browsable index of sailors and no name search over accounts. Account lookup is by exact email address or phone number only, and that is a deliberate decision taken because most sailors are minors. One route falls short of it: a sail-number lookup against the results corpus is open to any signed-in caller and is not restricted to their own numbers. That gap is R11.
No sailor data appears on any public page. Every dashboard path is excluded from crawling, nothing under the dashboard is ever in the sitemap, and the results pages require a signed-in account.
Media is private by default. Photos and video sit in a private bucket behind short-lived signed URLs. A URL is only minted after an access check on the record the file belongs to, and the server refuses to store a file reference that does not sit under the uploader's own prefix. There is a content-type allow-list and an automated test covering every media route.
Weight is minimised by design. Optional, private by default, recorded by a parent for under-13s, and never served as a trend line.
Competitive framing is age-gated. Rival and head-to-head framing is hidden for under-13s.
The rating is honest about what it does not know. Skill bands are unnamed percentile bands, not "national" or "international", because a raw percentile has not earned those words. Uncertainty is drawn on the chart. Below roughly the 55th percentile the product makes no normative judgement at all. After a sailor steps up a level, their first events are held in a neutral state so that a mid-fleet result at a bigger regatta can never read as regression. Self-reported results can never trigger a judgement.
Group AI insights are name-stripped before they leave the platform.
Moderation is an administrative function, not a coaching one. Reading reported private messages is restricted to club and system administrators and is club-scoped. Coaches are not moderators.
Every message sent is audit-logged, with the actor, the time, the IP address and the device, and a message cannot be edited or deleted by anyone. A report is logged too, but without the reporter's IP address or device — see R1.
Every route in the main API protects itself, and an automated check fails the build if a route is added without an authorisation decision. A second automated check fails the build if development is pointed at the production API, after a real incident in which it was. Those checks cover the main API only: the administration console, the authentication service and the club service are outside them, and the console uses a single gate over its whole surface rather than per-route decisions. Extending the checks is on the list in Security.

Proportionality: what we chose not to build

No advertising, no ad technology, no third-party marketing trackers, and no sale or sharing of personal data for anyone else's purposes.
No automated decision with legal or similarly significant effect. Nothing auto-selects a squad, awards a grade, or enters anyone for an event. Grading levels are awarded by a human coach and marked as confirmed by a human.
No biometric processing, and no collection of ethnicity, religion, disability, sexual orientation or dietary data — none of those fields exist.
No public profiles for children, and no sailor directory.
No payment or financial data.

The risk register

Ratings are our own assessment, on this scale:

Likelihood — Remote (would need an unusual combination of events) · Possible (plausible in normal use) · Likely (will happen if nothing changes).
Impact — Limited (inconvenience or minor loss of privacy) · Significant (serious distress, or disclosure of sensitive information) · Severe (harm to a child, or loss of records people depend on).
Rating — Low · Medium · Medium-high · High. High means we do not consider the processing acceptable as it stands: it either gets fixed on a date or gets switched off.

The three we rate highest

If you read nothing else here, read this. Every row in the table below looks alike; these three are not like the others.

An adult can message a child privately and nobody tells the parent. We think the underlying architecture is right — a parent sitting inside their teenager's conversations is surveillance, not safeguarding — but the compensating control is missing. A parent who is not a participant must at least be told that contact has started. Today they are not, the content checking would not catch anything that mattered, the Report button does not put the message in front of a human, and a coach with no DBS record at all is under no restriction. That combination is the most serious thing in this document.

A same-club adult needs no relationship at all to start that conversation. Children inherit their family's club, so this is not a corner case.

A thirteen-year-old can switch their parent off by editing one field. They do not need to be malicious to find it. Correcting a birthday they think is wrong is enough.

All three are dated below, and all three are the kind of change that gets shipped in weeks rather than quarters. That is why they are in a published document with a date on them.

The register

The dates in this register are the same dates recorded in the remediation table of the Safeguarding Policy. If one moves, both move.

#	Risk	Likelihood	Impact	Rating	Mitigations in place	Residual	Further action — owner — by
R1	An adult holds a private, unsupervised, indefinite conversation with a child. The guardian is not a participant by design, is never notified that it happened, and has to know to open a specific page to see anything. Automated content checking is a seven-word profanity list. Reporting a message notifies nobody and no screen displays the report queue. A lapsed, unverified or entirely absent DBS blocks nothing.	Likely	Severe	High	Guardians can read their minor child's message history; a message cannot be edited or deleted by anyone, so the record is immutable; every message sent is audit-logged with the account, time, IP address and device; adults outside the club need a connection first	High	Notify a guardian on first contact from a new adult, and on connection requests to a minor. Replace the profanity list with real detection of grooming indicators and route hits to administrators. Build a moderation screen that displays reported messages, alert a human when a report is filed, and record the reporter's IP address and device on a report as we already do on a send. Make verified DBS and safeguarding a blocking requirement — at minimum a club-configurable one — for adult-to-minor messaging. If not shipped, adult-initiated messaging to minors is turned off. — Engineering — 31 Dec 2026
R2	Any adult who shares a club with a child can open a direct conversation with them with no connection, no approval and no notification. Child accounts inherit the family club automatically. The fallback was built for club-wide and emergency broadcasts but is not limited to them.	Likely	Severe	High	Club membership is set by the club, not self-asserted; all of R1's logging and reporting applies	High	Restrict the same-club fallback to club-wide and emergency broadcast threads, so a one-to-one conversation with a minor always requires a connection. If not shipped, the fallback is removed entirely. — Engineering — 31 Dec 2026
R3	A minor can edit their own date of birth. Setting it twenty years back removes, in a single request and with no notification, their guardian's access to their profile, their messages, their coach notes and their session membership.	Possible	Severe	High	Date of birth is sanity-checked; a missing one fails safe to minor; a parent-managed account is not editable by the child	High	Make date of birth non-self-editable once set: changes by a minor require a guardian or an administrator, and the guardian is notified of any change. — Engineering — 31 Oct 2026
R4	A coach could set "Background Check: APPROVED" on their own profile and display it to parents as a labelled fact, bypassing the club-verified qualification system entirely and giving a false assurance of vetting nobody performed.	Possible	Severe	High	The verified qualifications system exists alongside it and is the real record	Low — mitigated in this release	The self-asserted field is removed from the profile form, the update schema and the profile display in the same release as this document, and the server rejects it if a client sends one. Still open, and narrower than the original risk: values asserted before this release may sit on old records and need purging; and a coach's free-text "certifications" box and the qualifications list on a public coach page are still typed by the coach and displayed with nothing marking them as unverified. Label every credential as verified or unverified. — Engineering — 31 Dec 2026
R5	Error-monitoring session replay recorded on-screen text and media unmasked, on a platform holding children's names, coach notes and medical information — 10% of all sessions and 100% of sessions with an error.	Likely	Severe	High	Authorisation and cookie headers were already stripped server-side	Medium — mitigated in this release	Text masking and media blocking are switched on in the same release as this document, and replay no longer attaches at all unless the visitor has accepted the analytics category. Still open: confirm the provider's region and replay retention period, and decide whether replay should run on signed-in pages at all — it does today. — Engineering — 31 Dec 2026
R6	A permanent analytics identifier was written to every visitor's browser on first page load, with no notice and no consent, stored with the full IP address and user agent, and used to link pre-signup browsing to the account afterwards. The 90-day retention rule that exists in the code points at the wrong collection and does nothing.	Likely	Significant	High	First-party only — no third-party analytics, advertising or marketing trackers anywhere; the data is never sold or shared	Medium	A consent banner with equal accept and reject ships in this release; nothing non-essential is written before a choice is made; a refusal or a sign-out deletes the identifier from the browser; Global Privacy Control is honoured without asking. Still open: make the retention rule actually run; stop storing the full IP address, or truncate it. See Cookies and similar technologies. — Engineering — 31 Mar 2027
R7	A child's full name was sent to a US language-model provider, alongside their coach's written feedback about them, on one analysis path.	Likely	Significant	Medium-high	One provider, one model; the provider's commercial terms do not train on API inputs; removing one environment variable removes all model processing and the product still works	Medium — mitigated in this release	The sailor's name is removed from every model path in the same release as this document: each prompt states the sailor is deliberately not named and instructs the model never to guess one, and coaches appear only as "Coach 1", "Coach 2". The coaching prose itself still crosses the Atlantic, and prose about one identified child is still personal data about them. Still open: a signed data processing agreement and a documented transfer mechanism with the provider, or the transfer stops. — Director — 31 Dec 2026
R8	Voice dictation sends a child's recorded speech to Google's speech recognition service before the transcript is processed. A comment in our own code stated that nothing is uploaded, which is wrong on the browsers most people use.	Likely	Significant	Medium-high	The transcript is only saved to the speaker's own notes; the feature is optional and clearly a dictation feature	Medium	The code comment is corrected, and the flow is disclosed in the Privacy Policy and the AI policy, in this release. Still open: tell the user at the point of use, before the microphone starts — nothing on the dictation screen says where the audio goes. Evaluate an on-device alternative. — Engineering — 31 Dec 2026
R9	Sensitive data about every minor at a club is concentrated on the club administrator role: medical notes, emergency contacts, dates of birth, phone numbers, and the content of reported private messages. The whole member list — names, dates of birth and parent email addresses for every minor at the club — can also be downloaded as a spreadsheet in one request, with nothing logged to record that it happened. No vetting requirement attaches to holding the role.	Possible	Severe	High	The role is club-scoped and cannot reach another club's members; a prior audit closed a cross-tenant leak	Medium-high	Require a verified safeguarding and DBS credential, or a written club attestation, before the role can be granted. Log access to welfare records and make that log available to the club. Log and rate-limit the member export, and strip date of birth from it. Make a role change write the canonical roles field and end the user's live sessions — today a demotion in the administration console updates only a legacy field and leaves existing sessions valid. — Engineering and Director — 31 Mar 2027
R10	We hold names, clubs, nationalities, age groups, results and derived performance metrics for thousands of competitors — mostly children — who never signed up, cannot reasonably be notified individually, and do not know the record exists. It is kept indefinitely.	Likely	Significant	High	Sourced only from already-published pages; never indexed, never public, never sold; every route serving it requires a signed-in account; there is no browsable index; aggregate rankings are administrator-only	Medium-high	Publish the Article 14 source notice (done in this release, in the Privacy Policy). Build a suppression list and an objection route so a removal request is permanent and survives the next crawl. Set a retention limit for results and GPS tracks. — Engineering — 31 Mar 2027
R11	Any signed-in user can supply an arbitrary sail number and get back every name ever associated with it and the person's full event history. A coach can therefore look up a child they have no relationship with, and the lookup leaves no trace.	Possible	Significant	Medium-high	Signed-in accounts only; no bulk export of the results corpus; aggregate views are administrator-only	Medium-high	Restrict lookups to numbers on the caller's own profile or their linked sailors, rate-limit the endpoint, and log every query. None of the three exists today, so nothing in the platform would show us this being misused. — Engineering — 31 Mar 2027
R12	There is no automated retention and no automated erasure. Deleting an account through the administrative route removes one record and leaves notes, messages, media, sessions and analytics behind. There is no self-service deletion and no data export. GPS tracks in cold storage have no expiry at all.	Likely	Significant	High	Authentication sessions expire and are revoked on password reset; a message cannot be edited or deleted, so the messaging record is at least complete; erasure and export requests are carried out manually by the director within one month	Medium-high	Build cascading deletion across every collection and the object store, and a self-service export. Add per-item deletion of a sailor's own reflections, which is the one thing a sailor writes and cannot remove. Until then, erasure and export are manual and are recorded as such in the Data Retention Schedule and Your data rights. — Engineering — 31 Mar 2027
R13	Backups are manual only. There is no automated backup job, and no tested restore. A database failure could lose coaching records that people rely on.	Possible	Severe	High	Object storage is separate from the database; race data can be re-derived from raw captures	Medium-high	Automated daily backup with a documented, tested restore, and a stated recovery point objective. This is the single largest gap in our security posture. — Engineering — 31 Dec 2026
R14	There is no way inside the product to report a safeguarding concern. The only reporting route is anchored to a message inside SailCoach, so it cannot report anything that happened at the club or on the water. Worse, that route does not reach a person: a report is written to a collection and the message is flagged, but nothing notifies anyone, no screen in the product shows the queue, and a report on a one-to-one conversation is scoped out of a club administrator's view entirely. A child who uses Report has told a database.	Possible	Severe	High	Every report is stored and the message is flagged, so the evidence survives even though nothing surfaces it	Medium	A monitored safeguarding address, [email protected], and a written procedure with response times and an escalation route that does not depend on the child's own club, are established by the Safeguarding Policy in this release, and every child-facing document now tells a child to use it rather than to rely on Report. Build the moderation queue screen and the alert behind the Report button (with R1). Build a standalone concern route usable by a child, a parent or a coach, with a named welfare contact and an out-of-club escalation path. — Director, then Engineering — 30 Jun 2027
R15	Photos and video of children can be uploaded and shared with no record of anyone's permission. There is no per-child image consent, no opt-out and no way for a parent to withdraw.	Likely	Significant	Medium-high	Media is private, access-controlled, never public, and never indexed; the access rules are covered by an automated test	Medium-high	Capture a per-child image permission from the guardian and enforce it at upload and at share. See Photographs and video. — Engineering — 31 Mar 2027
R16	Age is not verified in either direction and no acceptance of terms or privacy information is recorded for anyone. A request made directly to the signup endpoint creates an account with no date of birth and no parent email, because the age rules exist only in the browser.	Possible	Significant	Medium-high	An account with no date of birth is treated as a minor everywhere; a parent-created child account always has one	Medium-high	Require a date of birth on the server. Record acceptance of the terms and privacy information. Verify the parent email given at a minor's signup and act on it, rather than storing it as an unverified hint nobody contacts. — Engineering — 31 Mar 2027
R17	International transfers are unmapped. The main hosting region is not pinned anywhere, and the providers we use are US-headquartered. There is no EU Article 27 representative despite real EU users.	Likely	Significant	Medium-high	The set of providers is small and every one is listed publicly; nothing is shared with advertisers or data brokers	Medium-high	Confirm and publish the hosting region for the database, object storage and error monitoring. Put transfer agreements in place for each US processor. Appoint an EU representative or restrict EU signups. — Director — 31 Mar 2027
R18	Special category data can enter through any free-text box. A coach typing "asthma — inhaler in the kit bag" into a session note puts health data somewhere the medical-note access rules do not reach.	Likely	Significant	Medium-high	Notes are access-controlled by relationship; squad medical notes have no export path; the two designated medical fields are protected more tightly	Medium	Guidance at the point of writing, so a coach is told where welfare information belongs. Bring free-text coaching records inside the retention schedule. — Engineering — 30 Jun 2027
R19	Two features were labelled "AI" in the interface and contained no AI, one of them behind an animation that simulated a model working. Two genuine model outputs carried no label.	Possible	Limited	Medium	The genuinely templated race commentary correctly does not claim to be AI and carries a machine-readable provenance marker	Low — mitigated in this release	The AI framing is removed from both features in the same release as this document: the threshold-logic card is now "Training Patterns" and is not styled as AI, and the animation appears only over a real model call. Still open: label the two genuine model outputs, and drive every label from a provenance field so a future model swap cannot ship silently. Committed in How we use automated analysis and AI. — Engineering — 31 Dec 2026
R20	The skill rating and headroom judgement could be treated by a club as an automatic squad selection rule, turning advisory output into a decision about a child.	Possible	Significant	Medium	No automated decision exists in the platform; the judgement is advisory, shows its gates and evidence, stays silent below roughly the 55th percentile, and cannot be triggered by self-reported results; grading levels are human-awarded	Low	The AI policy states as a binding commitment that the rating and judgement must not be the sole basis for squad selection, team picks or event entry, that grade bands stay unnamed until calibration is published, and that grading remains human-awarded. Re-run the AI Act analysis if any of that changes. Separately, a sailor cannot switch the rating off; add a per-sailor control that hides the grade and the verdict while leaving the underlying results intact — Engineering — 30 Jun 2027. — Director — reviewed annually

Outcome

The assessment. With the mitigations described above, and subject to the dated actions in the register, we consider the processing proportionate to its purposes and able to proceed — with one condition. The three risks rated high after existing mitigations (R1, R2, R3) are not accepted. They are treated as ship-blockers with fixed dates, and if a date passes without the fix, the capability is withdrawn rather than the risk tolerated. The risks rated medium-high are accepted for now with the actions and dates recorded against them.

Residual risk position: medium-high overall, trending down. Six items on the register carry a mitigation that shipped in the same release as this document — R4, R5, R6, R7, R8 and R19. None of the six is closed outright; each has a named remainder against it. The rest are dated. We are not compliant today. The register above says where, and by when.

Open governance actions not tied to a single risk.

Complete the appropriate policy document required by DPA 2018 Schedule 1 Part 4 for our Article 9(2)(g) processing — Director — 31 December 2026.
Confirm a data processing agreement with each processor that receives personal data — Director — 31 March 2027.
Register with the ICO as a data controller and publish the registration number — Director — 31 December 2026.

Sign-off. This assessment is approved by the director of Innovology Ltd accountable for data protection. There is no data protection officer, for the reasons given under Consultation; accountability is not delegated.

Review. This document is reviewed at least every twelve months, and next by 17 September 2027. The open actions are re-rated on 31 December 2026. We will also revise it, before the change goes live, whenever the product changes materially — including if we:

introduce paid plans or a payment provider;
add a new processor, or send personal data to a new country;
name the skill-rating bands, or let any system rather than a person decide a sailor's level;
add a new model-driven feature, or change what is sent to a model provider;
introduce a real parental gate for under-13 signup, or otherwise change how age is established — today the age and parent-email rules are enforced only in the browser, and a child of any age can create a self-owned account with no parent involved (R16);
add automated decision-making of any kind that affects a person;
or open the results corpus to any audience wider than signed-in users.

If you think we have got this wrong. Tell us at [email protected], or use our Complaints Policy. For anything involving the safety of a child, use [email protected] and read the Safeguarding Policy first — it tells you what happens and how quickly. You can also complain to the Information Commissioner's Office at ico.org.uk/make-a-complaint, and you do not have to come to us first.