Data Breach and Incident Response

A personal data breach is a security incident that leads to the unauthorised access, loss, alteration, or disclosure of personal data, whether by accident or by a deliberate act. It does not only mean a hacker taking data out of our systems.

Examples that we treat as breaches include:

• Someone gaining access to an account, database, or backup they were not entitled to see.
• Personal data being lost or destroyed, including a failed backup or a deleted record we cannot recover.
• Personal data being changed without authorisation so that it is no longer accurate or trustworthy.
• Personal data being sent to, or made visible to, the wrong person.

Not every incident is a breach, and not every breach has to be reported. The sections below explain how we decide.

Any member of staff, contractor, or volunteer who suspects a breach must report it straight away to security@fleetfixer.io. We ask people to report early, even when they are not certain, because a fast report gives us more time to respond well.

Once a report comes in, a member of our security team logs it and begins triage. The aim of triage is to establish, as quickly as the facts allow:

• What happened, when it happened, and when we became aware of it.
• What categories of personal data and how many people are likely to be affected.
• Whether the data relates to children or includes wearable health data, which we treat with extra care.
• Whether we are acting as the controller or as a processor for a club or business.

We then assess whether the breach is likely to result in a risk to people's rights and freedoms. This assessment looks at how sensitive the data is, how easily someone could be identified, and what harm could follow, for example distress, discrimination, or financial loss. The outcome of this assessment drives whether and how quickly we notify the ICO and the people affected.

Containment runs in parallel with triage. Our first priority is to stop the breach getting worse before we worry about the full picture. Depending on the incident, containment can include:

• Isolating affected systems so that the problem cannot spread to the rest of the platform.
• Revoking credentials, API keys, and access tokens that may have been exposed, and forcing password resets where needed.
• Disabling compromised accounts and closing off the route the incident came in through.
• Preserving logs and evidence so we can understand what happened and support any later investigation.

Where we are the controller and a breach is likely to result in a risk to people's rights and freedoms, we will notify the Information Commissioner's Office (ICO) without undue delay and, where feasible, within 72 hours of becoming aware of it. This follows Article 33 of the UK GDPR. If we cannot provide all the detail within 72 hours, we report what we know and follow up in phases.

We send our report to the ICO breach line at ico.breach@ico.org.uk (or through the ICO's online reporting tool) and include the information the law requires, so far as we have it:

• A description of the breach, including the categories and approximate number of people and records affected.
• The name and contact details of our point of contact for the incident.
• The likely consequences of the breach.
• The measures we have taken or propose to take to address it and to limit any harm.

If, after assessment, a breach is unlikely to result in a risk to people, we may not need to report it to the ICO, but we still record it in our breach register (see section 7).

Where a breach is likely to result in a high risk to your rights and freedoms, and we are the controller, we will tell the affected individuals without undue delay. This follows Article 34 of the UK GDPR. We will use clear, plain language to explain what happened, the likely consequences, the steps we are taking, and what you can do to protect yourself.

Where we act as a processor for a club or business, the club or business is the controller and holds the duty to notify its own members and the ICO. In that case we will tell the controller promptly after we become aware of the breach, with the detail they need, so that they can meet their own obligations on time.

Some data carries more risk if it is exposed, so we handle it faster and with closer scrutiny.

• Children's data. Many clubs run junior sailing, so the Learn and Race platforms can hold data about under-18s. A breach involving children's data is escalated immediately and is more likely to meet the high-risk threshold for notifying the people affected.
• Wearable health data. Data synced through our Open Wearables bridge from devices such as Garmin, Polar, and Suunto can include heart rate and other health-related readings. We treat this as sensitive and prioritise both containment and notification accordingly.

We keep an internal breach register and log every personal data breach in it, including ones we decide we do not need to report. For each entry we record the facts of the breach, its effects, the assessment we made of the risk, and the action we took. This is an accountability requirement under the UK GDPR and it helps us spot patterns over time.

We keep each record for at least 7 years so that we, and the ICO if asked, can review how we handled an incident.

Once an incident is contained and any required notifications are done, we carry out a review. We look at the root cause, how our detection and response performed, and what we can change to reduce the chance of it happening again.

Improvements can include technical changes, updates to our processes and training, and changes to how we work with our sub-processors. We feed what we learn back into our wider security work, which you can read about in our security statement.