Security and Vulnerability Disclosure Policy

What this policy is

Two things. The first half sets out how Innovology Ltd, trading as SailCoach, protects the platform — accurately, including the parts that are weaker than we would like. The second half is our vulnerability disclosure policy: how to report a security flaw to us, what we will do about it, and our promise not to come after you for telling us.

If you have found something, skip to Reporting a vulnerability. The email is [email protected].

How we protect the platform

SailCoach holds records about children: names, dates of birth, medical notes, photographs and video of them sailing, private messages, which club they belong to and which stretch of water they sail on. That is the reason for everything below.

Accounts and sessions

• Everything travels over HTTPS. Nothing personal moves between your browser and us in the clear.
• Passwords are hashed, never stored. We raised the minimum length to ten characters, above the usual default, because of what this platform holds.
• The sign-in cookie is marked HttpOnly, so scripts in the page cannot read it, and Secure, so a browser will not send it over an unencrypted connection. It is also marked SameSite=None and partitioned, because the app and the administration console both talk to one API host. The consequence, which we would rather state than leave you to discover: there is one session per browser for the whole platform. Signing into the console replaces your session in the app, and the other way round. If you hold both kinds of account, use separate browser profiles.
• Sessions expire after seven days without use. There is no fixed maximum lifetime — a session in daily use keeps rolling forward. Resetting a password revokes every other session, so a stolen session does not survive a password change.
• Sign-in, sign-up and password-reset endpoints are rate limited, with the limits held in shared storage so they hold across every copy of the service rather than per server.
• Privileged fields cannot come from the client. Roles, account status, club membership and the parent-child link are set by the server. Sending them in a sign-up request does nothing.

Who can see what

• Every route in the main API protects itself. There is no single global gate that can be left open by accident — each part of the API checks permissions for itself, based on who you are and what has been shared with you.
• An automated check runs on every code change and fails the build if a route in the main API ships with no visible authorisation. Known exceptions are listed explicitly and reviewed, rather than being invisible.
• That check covers the main API only. The administration console takes the other approach — a single gate applied to its whole API surface — and it, the authentication service and the club service are not yet covered by the automated route and media checks below. Extending them is on the list at the end of this section.
• A second set of automated tests covers the access rules themselves — guardianship, what a parent may see, what a connected coach may see, what a club administrator may see — so a change to those rules cannot pass quietly.
• Sensitive fields are removed, not hidden. Medical notes, emergency contacts, dates of birth and phone numbers are stripped out of the data before it leaves the server for a viewer who should not see them.

Photos, video and documents

• Media lives in a private bucket. Nothing is publicly readable and there is no public media URL.
• Files are served through short-lived signed links, and every request is checked against who owns the file. A link or storage key belonging to someone else will not work — that check exists specifically to stop somebody swapping an identifier to read another family's photographs.
• Uploads are restricted to an allow-list of file types. Formats that can carry an attack when opened in a browser, such as HTML and SVG, are refused.
• Every route in the main API that can hand out a file is required to appear in an access-control test, and a build check fails if one is added without being tested.

Logging

This is thinner than we would like.

• Messages sent are audited. Every message sent is recorded with the sender, the time, the IP address and the browser, so a safeguarding question can be answered with evidence rather than recollection. A report of a message is recorded with the reporter and the time, but not yet with the IP address or browser — that is a gap and we are closing it. There is no way to edit or delete a message in the product, so there is nothing of that kind to log.
• One other class of action is logged today: when a parent acts on behalf of their child, we record the parent, the action, the child, the time and the IP address.
• Sign-ins, failed sign-ins, sign-outs, password changes, permission denials and role changes are not yet logged. The code to write those records exists but is not yet wired to the places that would call it, so the security audit trail is close to empty. We are not going to describe a control we do not operate. Building the rest of that trail is on the list below.

Build and environment

Automated security checks run on every proposed change, and the build fails if any of them fails. The first two look at the main API only; the other three look at the whole repository:

• Production and test data are separate. Our automated tests never touch production data — every test run creates its own throwaway database.
• A "dev-hits-production" guard fails the build if the application could be configured to point development at the live API. It exists because that mistake was actually made once, and read real users' data.

What we do not claim

• We do not claim data is encrypted at rest. Our hosting provider may encrypt its storage; 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.
• We have not had a penetration test. No independent security assessment of the platform has been carried out.
• We have no 24/7 security operations centre and no formal incident-response retainer. We are a very small team.

Backups — the honest position

We do not currently run automated backups of the main database. Snapshots are taken manually, and there is no point-in-time recovery. A serious infrastructure failure could lose data that you would not get back.

We are not comfortable with that, automated backups are a priority piece of work, and until it ships we will not write a durability promise we cannot keep. Practically: keep your own copy of anything you cannot afford to lose. This is also covered in our Terms of Service.

What we are working on

Automated backups; a complete authentication and privilege-change audit trail, and the IP address on a message report; extending the automated route and media checks to the administration console, the authentication service and the club service; independent security testing before we charge anyone for the service; and self-service account deletion.

Reporting a vulnerability

We would rather hear about a flaw from you than read about it somewhere else. Reporting one in good faith is a service to the children whose data we hold, and we treat it that way.

Email [email protected].

What is in scope

Report a flaw in someone else's product to that vendor, not to us. If you are not sure who owns it, ask us and we will tell you.

Things we already know about and are not looking for reports on: output from an automated scanner with no demonstrated impact; missing security headers with no working exploit; email configuration opinions (SPF, DMARC, DKIM); software version numbers without a working path to exploit; self-inflicted issues that need the victim to paste code into their own browser; and the gaps we have already published on this page, including the absence of automated backups.

How to report

Send us:

• what you found and why it matters — what could someone actually do with it;
• where — the domain, URL or endpoint;
• how to reproduce it, step by step. A short screen recording is fine;
• whether you accessed, downloaded or retained any data that was not yours, and confirmation that you have deleted it;
• how you would like to be credited, or that you would rather not be.

Encrypted mail is welcome; ask us and we will arrange a key. Please do not open a public issue, post it on social media, or tell us through a coach or a club.

What we will do, and when

Working days are Monday to Friday, excluding public holidays in England and Wales.

If a flaw is being actively exploited, say so in the subject line. That gets a same-day response wherever we humanly can.

Publishing. Please give us a chance to fix it before you tell anyone else. Ask us and we will agree a timeline; if we cannot agree one, assume 90 days from your report. If a fix is going to take longer than that, we will tell you why and keep talking rather than go silent. We will not ask you to stay quiet indefinitely.

Rules for your research

These are the conditions of the safe harbour below. Our authorisation extends to testing done within them. If you overshoot by accident, the authorisation does not stretch backwards to cover it — nobody's can, that is how the Computer Misuse Act works — but our commitments below still apply in full: tell us, and we will not pursue you for it and we will not treat it as anything other than what it was.

Do not access, alter, download or keep anybody else's data. This is the rule that matters most here, and it is not a formality. The records in this platform are mostly about children — their medical notes, photographs and video of them, private messages, their date of birth, their club and where they sail. If you find a way to read a record that is not yours:

• stop at the exact point you can prove the flaw exists;
• do not enumerate, do not download, do not take a screenshot of the content — a screenshot of the URL and the HTTP status is enough;
• redact any name, image or personal detail from what you send us;
• delete anything you obtained, and tell us you have;
• tell us immediately, not after you have finished exploring.

Proving an access-control flaw with one deliberately-created test account is research. Pulling a hundred children's records to show the scale of it is not, and we will treat it as what it is.

Also, do not:

• run denial-of-service or load tests, or anything else designed to degrade the service. A sailing session happens on a particular afternoon and does not come round again;
• run automated scanning that degrades performance. Rate-limit yourself. Our authentication endpoints are rate limited, and tripping those limits locks out real users;
• brute-force credentials, or use credentials found in a breach dump;
• socially engineer anybody — our team, our users, coaches, clubs, parents or children. No phishing, no pretexting, no "just testing" messages to a sailor;
• attempt physical access to anything, or attack our suppliers;
• plant malware, backdoors or persistence, or change or delete anything that is not yours;
• contact children through the platform as part of any test, under any pretext.

Use accounts you create yourself. If you need something we cannot give you through a normal sign-up — a coach account, a club, a parent-child link — email [email protected] and ask. We would rather set you up properly than have you improvise against live accounts.

Our commitment to you

If you follow this policy in good faith:

• We will not bring a civil claim against you, and we will not report you to the police for your research. One qualification, because you should know it now rather than discover it later: if your testing reached real records about real children, we have duties of our own that do not bend for us. We must report a qualifying personal data breach to the Information Commissioner within 72 hours, and we must pass information on where a child is at risk. Those reports are about the incident, not about pursuing you, and we will tell you if we have to make one and what we said in it.
• We authorise the testing described above. As far as we are concerned, access made within these rules is authorised access, not unauthorised access, and we will say so plainly and in writing if anyone asks. We cannot bind a prosecutor or a third party — nobody can — but our position will be on the record and it will not change.
• One limit on that authorisation, because it is not obvious. Our consent covers the Computer Misuse Act 1990, where what matters is consent from the person entitled to control access — and for our own systems, that is us. It does not cover section 170 of the Data Protection Act 2018, which makes it an offence to obtain personal data without the controller's consent. For most of what is on SailCoach we are the controller and our consent is enough. For some of it we are not: a club is a controller in its own right for some records, and the published race results we ingest belong to the organising authorities that published them. We cannot give consent on their behalf and we are not pretending to. This is the practical reason the rule above says stop at the exact point you can prove the flaw — stopping there is the only place where the question does not arise.
• Your report will not be treated as a breach of our Acceptable Use Policy. That policy says the same thing from the other direction: researching a vulnerability is welcome, testing one on live data is not.
• If you tell us in good faith that you crossed a line by accident — you saw more than you meant to, you got further than you expected — that is exactly the kind of thing we want reported, and it will not be used against you.

We will apply this in the spirit it is written. If your work was genuinely a good-faith attempt to make this safer for the children on it, we are on your side.

Bounties and credit

We do not pay bounties. SailCoach is free to use and we are a very small company; we would rather be honest about that than dangle a reward we cannot fund. If that changes, this page will change with it.

We do give credit. If you want it, we will name you — your name, handle or a link — when we publish the fix, and we will describe what you found accurately rather than minimising it. If you would rather not be named, that is equally fine, and we will not name you by accident.

When personal data is breached

A security incident that exposes personal data is a data protection matter as well as a security one. This is what we do.

Telling you

If a breach is likely to result in a high risk to your rights and freedoms, we will tell you directly and without undue delay. We will tell you:

• what happened and roughly when;
• what data was involved — specifically, not vaguely;
• what the likely consequences are;
• what we have done about it and what we are still doing;
• what you should do, if anything;
• who to contact for more.

We will write it in plain language. Where a child's data is involved, we will tell the child's parent or guardian, and where the child is old enough to understand it, we will provide a version written for them.

Where children's data is involved, we treat the high-risk threshold as met unless we have a clear, recorded reason to conclude otherwise. We would rather tell a family about an incident that turned out to be minor than decide on their behalf that they did not need to know.

If we cannot identify everyone affected — which is a real possibility for the race-results data we hold about people who never signed up — we will publish a notice instead, and it will be findable rather than buried.

Telling the regulator

We will report a qualifying personal data breach to the Information Commissioner's Office within 72 hours of becoming aware of it, as required by the UK GDPR. If we do not have the full picture within 72 hours we will report what we have and follow up, rather than delay the report while we investigate.

Where the breach happens at one of our suppliers, they are required to tell us without undue delay, and we assess and report it from there. Where a club is a data controller in its own right for the data involved, we will tell the club promptly so that it can meet its own obligations.

We keep an internal record of every personal data breach, including the ones we assess as not reportable, together with the reasoning for that decision. That record is itself a legal requirement, and it is what an auditor would ask to see first.

If you think your data has been caught up in an incident, contact [email protected]. Your rights, and how to complain to the ICO, are set out in Your Data Rights and the Privacy Policy.

Review and contact

We review this policy at least once a year, and whenever our security position changes materially — including when automated backups or an independent security test are in place, both of which will change what this page says. Next scheduled review: 17 September 2027.

• Security reports and research: [email protected]
• Personal data questions: [email protected]
• Anything else: [email protected]

Related documents

• Privacy Policy
• Your Data Rights
• Acceptable Use Policy
• Terms of Service
• Subprocessors
• Complaints Policy