Data Retention Schedule
What this document is
This is the list of everything SailCoach holds about people, how long we intend to keep each kind of record, why that period, and — the part that matters most — whether the deletion happens by itself or because a person does it by hand.
Innovology Ltd is the data controller. It trades as SailCoach and is registered in England and Wales.
Read this alongside the Privacy Policy, which explains what we collect and why, and Your Data Rights, which explains how to ask us to delete something.
The honest position on automation
Almost nothing on this page deletes itself today.
We audited the codebase in September 2026 to write this document. There is no scheduled purge job, no retention cron, and no self-service account deletion in SailCoach. Account deletion is an administrator action, and the routine behind it removes the account record but leaves related records — notes, media, messages, analytics — behind. Only two expiries genuinely run on their own:
- Login sessions expire after seven days and are revoked when you change your password.
- The cache of race GPS data in our fast-access store expires on a timer — but the permanent copy in object storage does not.
There is one 90-day deletion rule written into a database model for analytics events. It points at a collection name the application never writes to, and the file containing it is not loaded by the running service. We have not verified that it exists on the live database, so we do not count it. Treat analytics retention as indefinite until we say otherwise here.
So this document does two things. It states the periods we are committing to as policy, and it tells you truthfully which ones a machine enforces (almost none) and which ones a human has to carry out. Where a period is manual, it still binds us — but it depends on us doing it, which is weaker, and you deserve to know that.
What we do in the meantime. Deletion and retention are handled as a written manual procedure. Requests go to [email protected], are acknowledged within five working days, and are worked through store by store using the tables below as the checklist. We keep a dated record of every request and what was removed, so that the work is auditable even though it is not automated.
What we are committing to build. In priority order:
- A cascading account-deletion routine that removes every record listed below, including files in object storage, in one operation.
- A self-service "download my data" export, so an access request does not depend on us assembling it by hand.
- A working scheduled purge for analytics events, audit logs and expired invitations.
- A suppression list for race-results data, so that removing someone also stops a later crawl re-importing them.
- Self-service account closure, so you do not have to email us to leave.
- A delete control for a sailor's own reflections, which is the one thing a sailor writes that they cannot currently remove themselves.
We will update this page when each lands, and the version history on this page is the record. Until an item appears in the "Enforced" column as automatic, assume it is a person doing it.
How to read the tables
| Marking | Meaning |
|---|---|
| Automatic | Code deletes or expires the data without anyone acting. |
| Manual | A person deletes it, either as routine housekeeping or when you ask. It will not happen on its own. |
| Indefinite | Nothing deletes it today and no period is enforced. The target period in the row is our policy intent, not current behaviour. |
Account and profile data
| Record | What it is | Target retention | Why this period | Enforced |
|---|---|---|---|---|
| Account record | Name, email, password hash, date of birth, roles, club, profile photo, last sign-in | While your account is open, then deleted within 30 days of closure | You need it to sign in. The 30 days is a grace period in case a closure was a mistake or a dispute is open | Manual |
| Guardian links | Which parent is linked to which child | With the child's account. The oversight the link grants ends automatically on the child's 18th birthday | The link is what makes parental oversight work; it stops mattering at adulthood | Oversight ends Automatic; the record is Manual |
| Emergency contact | A parent or carer's name, relationship and phone number | While the sailor's account is open, then deleted within 30 days of closure | It only exists so someone can be reached if a sailor is hurt on the water | Manual |
| Sign-in credentials and linked Google account | Password credential row, OAuth account link | With the account | Nothing to keep once the account is gone | Manual |
| Login sessions | The session token that keeps you signed in | 7 days, refreshed while you are active. Revoked immediately when you change your password | A short session limits the damage from a stolen or shared device | Automatic |
| Email verification tokens | One-time links | Expire shortly after they are issued, set by our sign-in library | Single-use security tokens should not outlive their use | Automatic (expiry); the row itself is Manual |
| Invitations — parent link, connection | Invitee email, child name, personal message, token | The invitation stops working 7 days after it is sent. Target for deleting the record: 30 days | An unaccepted invitation is stale quickly, and it names a second person | Expiry Automatic; deletion Indefinite (a scheduled clean-up exists in the code but is switched off) |
| Notification records and preferences | Notification bodies, channel settings | 12 months, then with the account | You may want to look back at a notification for a season; beyond that it is noise | Indefinite |
Coaching and training records
These are the heart of the product: what a sailor did, what a coach thought, and how it changed.
| Record | What it is | Target retention | Why this period | Enforced |
|---|---|---|---|---|
| Training sessions | Session title, description, notes, location, objectives, equipment, weather, timeline, per-sailor notes | While the sailor's account is open, then deleted within 30 days of closure | A training history is only useful to the sailor it belongs to | Manual |
| Coach notes about a sailor | Free text, title, shared/private setting, attached video and the shapes a coach drew on it | While the sailor's account is open, then deleted within 30 days of closure | Same reason. A note about a child should not outlive the child's use of the platform | Manual |
| Private coach assessments | Summary, strengths, areas to improve, homework, and technical, tactical, physical, mental and safety ratings | While the sailor's account is open, then deleted within 30 days of closure. We are reviewing whether physical and mental ratings should be kept at all | These are opinions about a child, several of them health-adjacent. They should not accumulate | Manual |
| Session feedback and skill assessments | Ratings and prose from coach to sailor | As above | As above | Manual |
| The sailor's own notes, reflections and goals | Content you wrote, images you attached, milestones, progress | As above | It is yours | Per-item deletion of notes, goals and images is available in the app. A reflection cannot be deleted in the app — there is no delete route for one. Ask us and we will remove any reflection, usually within days; adding the control is on the build list. Bulk deletion is Manual |
| Squad membership, attendance, availability, grading history | Who was on the water on which day, and how their level changed | While the squad season is running, then to the end of the following season | Clubs need last season to plan this season. Two seasons back has no operational use | Indefinite |
| Safety briefings and acknowledgements | Briefing content and who confirmed they had read it | 3 years from the session | This is the record that a safety briefing was given. It is the kind of record that matters if something is later questioned | Indefinite |
| Volunteer roster | Volunteer name, email, phone, job assignments | End of the following season | A roster is an operational document for the season it covers | Indefinite |
Messages
| Record | What it is | Target retention | Why this period | Enforced |
|---|---|---|---|---|
| Direct messages | Message text, attachments, sender name and photo | While both accounts are open. On closure, your sent messages are removed within 30 days | Conversations belong to the people in them | Manual |
| Messages withdrawn by a moderator | A message an administrator rejected on review. Nobody using the product can delete or edit a message — this is the only route by which one is ever taken down | Marked withdrawn immediately and hidden from everyone. The text stays in the database until the account is deleted | Withdrawal is a hide, not an erase, so that a safeguarding concern can still be investigated afterwards. We are changing this so the text is actually removed 30 days after withdrawal | Automatic (hiding); erasure is Indefinite |
| Message audit log | Who sent or reported a message, and any moderation decision taken on it, with IP address and browser string where we capture them | 12 months | Long enough to investigate a safeguarding or abuse question. Beyond that it is a log of children's IP addresses with no purpose | Indefinite |
| Moderation flags | The output of the automatic check on a message. That check is a short list of offensive words and nothing more — it does not detect grooming. A pattern-based grooming check exists in our code but is not applied to messages; the date for connecting it is in the Safeguarding Policy | 12 months, or under the safeguarding rule below if it leads to a concern being raised | Same reasoning | Indefinite |
| Message reports and their outcome | Who reported what, why, and what was decided | Where the report concerns a child: until that child's 25th birthday. Otherwise 3 years | This follows common practice in youth sport — a safeguarding record needs to be available long after the child has left, because concerns can surface years later. See our Safeguarding Policy | Indefinite |
Photos, video and other media
| Record | What it is | Target retention | Why this period | Enforced |
|---|---|---|---|---|
| Profile photos, session photos, note images | Image files in private object storage, plus the database record naming them | With the record they belong to; deleted within 30 days of account closure | The picture and the record should die together | Manual — and note that our current administrative deletion routine does not remove the underlying file from storage. Removing files is a separate manual step today |
| Coaching video of sailors, and transcoded versions | Video of a sailor on the water, with a coach's timestamped annotations | With the coach note it belongs to; deleted within 30 days of account closure | Video of a child is high-risk data and should not sit around detached from its purpose | Manual, with the same storage caveat |
| Event and session media | Photos and documents attached to an event or session | 3 years from the event, or on request | Long enough to be a record of the season; not forever | Indefinite |
We do not currently capture consent for taking or using images of children — see the Image Use Policy for what that means and what we are doing about it. A parent can ask us to remove any image of their child at any time, and we will, regardless of the periods above.
Health, welfare and vetting data
This is the most sensitive material we hold, and the periods are correspondingly short.
| Record | What it is | Target retention | Why this period | Enforced |
|---|---|---|---|---|
| Medical notes on a profile | Free text, up to 1,000 characters, written by the sailor or their parent | While the account is open, then deleted within 30 days of closure. Deleted immediately on request without needing a reason | Health information about a child should exist for exactly as long as it is needed to keep them safe on the water, and not a day longer | Manual |
| Squad medical notes | Free text, up to 500 characters, written by a head coach about a named child | While the sailor is in the squad, then deleted at the end of that season | A medical flag is only useful to the coach running that day. It has no archival value | Indefinite |
| Body weight entries | A history of weight readings for a sailor, some recorded by a parent for under-13s | We aim to keep only the most recent 24 months of entries | Boat and rig decisions need a recent figure. An adolescent's weight history is not something we should accumulate | Indefinite — you or your parent can ask us to delete the history or any entry, and we will |
| Coach qualification records | Qualification type, issuer, expiry, and who at the club verified it | While the coach holds the qualification, plus 12 months after it lapses | Clubs need to see cover was in place for a past season | Indefinite |
| DBS check records | Type, reference number, uploaded evidence, who verified it and when, expiry date | The certificate reference and any uploaded evidence file should be deleted within 6 months of the verification decision, in line with the DBS Code of Practice. We keep only the fact a check was done, its date, its expiry and who verified it | A DBS certificate is criminal-offence data. The recruitment decision, not the certificate, is what needs to persist | Indefinite — today the reference and evidence file are retained. This is the single retention gap we most want to close, and it is on the build list above |
The lawful bases for this material are set out in full in the Privacy Policy, and this document does not depart from them: explicit consent under Article 9(2)(a) where a sailor or their parent records health information; vital interests under Article 9(2)(c) in an on-water emergency; and the substantial public interest condition, Article 9(2)(g) with the safeguarding of children condition in Schedule 1, Part 2, paragraph 18 of the Data Protection Act 2018, where health information forms part of a safeguarding concern. A DBS record is criminal offence data under Article 10, held under the consent condition in Schedule 1, Part 3, paragraph 29 of the Data Protection Act 2018 — the coach chooses to record and upload their own check and can withdraw it — with legitimate interests as the Article 6 basis.
Race results and GPS tracks
Some of this is about our users. A great deal of it is about people who have never used SailCoach — sailors whose names appear in published regatta results that we collect from club websites, results archives and tracking providers. Most of them are children sailing Optimists. If you are one of them, or a parent of one, Your Data Rights has a section written for you.
| Record | What it is | Target retention | Why this period | Enforced |
|---|---|---|---|---|
| Published results rows | Position, sail number, helm name, crew name, club, nationality, age group, gender, race scores and penalty codes — plus the original page we took them from | Indefinite while the results remain part of a sailing record we are asked to analyse. Deleted for any named individual on request | Race results are published records and the corpus is what makes performance analysis possible. That is a legitimate interest, but it does not outweigh a person's objection, so the request route is the control | Indefinite, removal is Manual |
| Cross-event sailor records | Every helm name ever seen on a sail number, every event, whether they helmed or crewed, first and last seen | Same | Same | Indefinite, removal is Manual |
| Identity clusters and competitive ratings | Name clusters built by fuzzy matching, and the rating we calculate from them | Same. Deleted, with the underlying rows, on request | Same | Indefinite, removal is Manual |
| Derived race analysis for every boat in a fleet | Start position, speeds, distance, penalties, places gained per leg | Same | Same | Indefinite, removal is Manual |
| GPS tracks | Timestamped latitude, longitude, heading and speed for each named boat through a race | The working cache expires on a timer. The permanent copy has no expiry and is never deleted on a schedule | The permanent copy exists because re-collecting a race from a provider is often impossible — the provider may have removed it. That is an honest reason, and it is also why this data is effectively permanent unless you ask us to remove it | Cache Automatic; permanent copy Indefinite |
| Venue coordinates on a sailor's events | Where an event was held | With the event record | It describes the event, not the person | Manual |
The honest limitation. Until we build the suppression list described above, removing someone from the results corpus is a one-time deletion. A later scheduled crawl of the same club website could re-import the same published page and re-create the record. We therefore keep a written list of every removal request, and we re-check and re-apply them. That is a manual compensating control for a missing technical one, and we are replacing it.
We also cannot change the original result on the club's or the results archive's own website. That is theirs, not ours. We will tell you who to contact.
Analytics, logs and security records
| Record | What it is | Target retention | Why this period | Enforced |
|---|---|---|---|---|
| Analytics events | Page views, clicks, form submissions, time on page, referrer, query string, screen size, browser, operating system, full IP address, full browser string, user ID or anonymous ID | 90 days | Three months is enough to understand how the product is used and to fix what is broken. Keeping identifiable browsing longer serves no purpose we can justify | Indefinite. The 90-day rule exists in the code but points at a collection nothing writes to, so we do not believe it is running. We will not claim 90 days as fact until we have verified it on the live database |
| Signup journey reconstructions | A per-signup trace of the pages a person visited before registering, stitched from the anonymous ID to the account | Derived from analytics events, so the same 90 days | Same | Indefinite |
| The anonymous visitor ID in your browser | A random ID stored in your browser's local storage that ties your visits together, and is linked to your account when you register. It is written only if you accept the analytics category | Deleted from your browser when you withdraw analytics consent and when you sign out. It does not otherwise expire on a timer. Target: a fixed 6-month lifetime | An identifier that never expires is not a session, it is a permanent tag | Clearing on sign-out and on withdrawal is Automatic; the 6-month timer does not exist yet. See the Cookie Policy |
| Security audit log | User ID, action, resource, IP address, browser string | 12 months | Long enough to investigate a compromise or an access dispute across a season | Indefinite |
Data held by our suppliers
Some records live with companies that work for us, and their retention is set by their systems, not ours. Everyone below is listed in full, with what they receive and where, in Subprocessors.
| Supplier | What they hold | Target retention | Enforced |
|---|---|---|---|
| Sentry — error monitoring | Error reports from our servers and your browser, with your email, username and user ID attached. Also session replays: a recording of what was on your screen, for 1 in 10 sessions and for every session where an error happened | 90 days. We have not yet confirmed the actual period configured on our Sentry account, so we are not stating it as fact. Replays are masked before they leave your browser — all text obscured, all media blocked — and replay only runs for someone who has accepted the analytics category. Error reports and performance traces are sent whatever you choose about cookies. Whether replay should run on signed-in pages at all is still an open question on our DPIA register | Set by Sentry, not confirmed |
| Resend — transactional email | Email addresses, recipient names, invitation content and delivery status for every email we send. We also store Resend's message ID against the invitation record so we can check whether an email arrived | 12 months for delivery records. Not yet confirmed with Resend. The message IDs we store are removed with the record they belong to | Set by Resend, not confirmed |
| Anthropic — AI analysis | Coach feedback text and voice-note transcripts, sent to be summarised. No sailor is named in any request. See How we use AI | Our intent is that no copy is retained beyond the request. We have not yet confirmed that zero-retention terms apply to our account | Not confirmed |
| Google — sign-in | Your Google identity if you sign in with Google | Governed by your Google account, not by us | Set by Google |
| Railway — hosting, database, object storage | Everything | For as long as we hold it. Deleting from our database deletes it from Railway | Follows this schedule |
Backups
We take manual database snapshots. There is no automated backup schedule, no automated rotation and no point-in-time recovery. We are stating this because it has a consequence you are entitled to know.
- Target: a snapshot is kept for 35 days and then destroyed.
- This is manual. There is no code that takes a snapshot or expires one.
What this means for a deletion request. When we delete your data from the live system, a snapshot taken before that point may still contain it. We cannot reach inside a snapshot to remove one person. What we do instead is the approach the Information Commissioner's Office accepts: the data in a snapshot is put beyond use. It is not available to anyone in the ordinary course, we do not use it for any purpose, and if we ever restore a snapshot we re-apply every outstanding deletion immediately afterwards. The data then disappears for good when that snapshot is destroyed.
Every organisation with backups has this limitation. No backup system can deliver instant, total erasure, and we are not going to imply that ours does.
Legal holds
We will keep data beyond the periods on this page, and will decline to delete it, where we need it for one of these reasons:
- A safeguarding concern. If a record is part of a concern about a child's welfare, it is preserved under the safeguarding retention described above, even if the person asks us to delete it. Protecting a child takes priority over a deletion request, and we rely on the safeguarding conditions in Schedule 1 of the Data Protection Act 2018.
- A legal claim. If we are involved in, or reasonably expect, a legal claim or a dispute, we preserve what is relevant to it until it is resolved.
- A request from a regulator, the police or a court. We preserve what we are lawfully required to preserve.
- A live investigation of misuse of the platform. Fraud, abuse, or a security incident.
If we apply a hold to something you have asked us to delete, we will tell you that we have, and why, unless telling you would itself prejudice a safeguarding investigation or a criminal enquiry.
What happens when your account closes
Today there is no button that closes your account. You ask us at [email protected] and a person does it. We are building the button.
When you ask us to close your account:
- We acknowledge within five working days and confirm what closing will remove.
- We delete the account record, which ends sign-in there and then. We have no way to suspend an account short of deleting it, so closure is the only stop available.
- We then work through every other store in this document by hand, including files in object storage, because deleting the account record does not cascade to any of them. That hand-work is why closure takes days rather than seconds, and it is the top item on the build list above.
- We complete this within 30 days of your request, or of receiving anything we needed in order to identify you.
- We write to you to confirm what was deleted and what was kept, and why anything was kept.
What we keep after closure, and why:
| Kept | For how long | Why |
|---|---|---|
| Safeguarding records concerning a child | Until that child's 25th birthday | See above |
| Security audit entries recording the deletion itself | 12 months | So we can prove the deletion happened |
| Messages you sent to other people, in their copy of the conversation | With their account | A conversation is two people's record, not one person's |
| Anything under a legal hold | Until the hold lifts | See above |
| A record that a person with your email address asked for deletion | Indefinitely, as a minimal note | So we do not re-create the account from a stale invitation or a later import |
Closing a parent's account does not close their child's, and closing a child's account does not close their parent's.
Questions and requests
Email [email protected]. We acknowledge within five working days and complete requests within one month, as Your Data Rights sets out in detail.
We have not appointed a Data Protection Officer. We are not a public authority and our processing does not currently meet the threshold in Article 37 of the UK GDPR, but we keep that under review as we grow — and privacy requests reach a monitored inbox either way.
If you think we are keeping something for too long, or for no good reason, tell us. That is a legitimate complaint and we would rather hear it than have you assume we thought about it. You can also complain to the Information Commissioner's Office at ico.org.uk/make-a-complaint, and to us first via Complaints.