Data Processing Agreement

1. What this is and why it exists

Article 28 of the UK GDPR says that where one organisation processes personal data on behalf of another, there must be a written contract containing specific terms. This is that contract.

• The Club is the controller. It decides what personal data to collect about its members and why.
• Aurelia Technology Consulting Limited ("Sail") is the processor. We hold and handle that data on the Club's instructions and for no purpose of our own.

This agreement forms part of the Terms and conditions and takes effect when the Club starts using Sail. Where the two conflict on data protection, this document wins.

In this agreement, "data protection law" means the UK GDPR, the Data Protection Act 2018, and the Privacy and Electronic Communications Regulations 2003, each as amended.

2. What we process, and for whom

The details required by Article 28(3) are in Annex A. In summary:

• Subject matter: providing the Sail club management service.
• Duration: for as long as the Club subscribes, plus the retention period in section 10.
• Nature and purpose: storing, organising, retrieving, transmitting and deleting personal data so the Club can run its club.
• Types of personal data: including special category data (health and dietary information) and criminal offence data (DBS and safeguarding records). See Annex A.
• Categories of data subject: club members including children, prospective members, guardians, club officers, paid staff, instructors, and non-member customers.

3. Our obligations

We will:

(a) Process only on the Club's documented instructions. The Club's instructions are: this agreement, the Terms, and what the Club does through the Sail interface. We will not process personal data for any other purpose. If we believe an instruction breaks data protection law, we will tell the Club and may pause that processing until it is resolved.

(b) Keep it confidential. Everyone we authorise to access personal data is bound by confidentiality obligations and is told what they may and may not do with it.

(c) Keep it secure. We will implement and maintain appropriate technical and organisational measures under Article 32. What those are today is set out in Annex B. We may improve them; we will not reduce them below the standard in Annex B.

(d) Use sub-processors only under section 5.

(e) Help the Club answer people. If a member exercises a right, whether access, correction, erasure, restriction, portability or objection, we will help the Club respond, taking account of what we can see and do. Sail includes a request process that routes a member's deletion request to the Club for a decision, because the decision is the Club's to make. Where a member contacts us directly, we will not respond substantively; we will tell them to contact their club, and tell the Club without undue delay.

(f) Help the Club meet its own duties under Articles 32 to 36, covering security, breach notification, data protection impact assessments and prior consultation, taking account of the information available to us.

(g) Tell the Club about breaches. If we become aware of a personal data breach affecting the Club's data, we will notify the Club without undue delay and in any event within 24 hours, with what we know: what happened, who is likely affected, the likely consequences, and what we are doing. We will keep the Club updated. The Club, as controller, decides whether to notify the ICO and the people affected. The 72-hour clock is the Club's, which is why ours is shorter.

(h) Delete or return the data at the end, under section 10.

(i) Demonstrate compliance. We will make available the information needed to show we meet Article 28, and allow audits under section 9.

4. The Club's obligations

The Club will:

• ensure it has a lawful basis for everything it collects, and a condition under Article 9 for health data and Article 10 and DPA 2018 Schedule 1 for safeguarding and DBS records. For most clubs the relevant condition is substantial public interest: safeguarding of children and of individuals at risk (Schedule 1, Part 2, paragraph 18), which also requires an appropriate policy document. We mention this because most clubs are not aware of it, but the Club should confirm its own position rather than relying on ours;
• give its members a privacy notice explaining what it collects, why, and who it shares it with, including that Sail is used;
• keep instructions to us lawful;
• manage who at the club has access, and remove people promptly when they leave;
• not put personal data into free-text fields where it does not belong.

5. Sub-processors

The Club gives general authorisation for us to use sub-processors. Those in use today are listed in Annex C, with what each does and where it is located.

If we intend to add or replace a sub-processor, we will give the Club at least 30 days' notice by email. If the Club objects on reasonable data protection grounds within that period, we will work in good faith to find an alternative. If we cannot, the Club may terminate its subscription without penalty and receive a pro rata refund of fees paid in advance.

Every sub-processor is bound by written terms no less protective than these, and we remain fully liable to the Club for what they do.

Our marketing website uses Google Analytics. It does not run in the Sail application, and it never receives club or member data, so Google is not a sub-processor under this agreement.

6. International transfers

Where personal data is transferred outside the UK, it is covered by one of:

• UK adequacy regulations, which cover the European Economic Area; or
• the UK Addendum to the EU Standard Contractual Clauses, or the UK Extension to the EU-US Data Privacy Framework where the provider is certified under it; together with
• a transfer risk assessment, and additional safeguards where the assessment requires them.

The location and mechanism for each sub-processor are recorded in Annex C.

The Sail database is hosted in the United Kingdom. Club and member records are not transferred outside the UK by being stored.

7. Special category and criminal offence data

Sail is built to hold health information and safeguarding records, because clubs cannot run safely without them. That brings specific commitments:

• Health, dietary and safeguarding data is treated as special category or criminal offence data and is subject to the access restrictions in Annex B.
• Sail's AI features do not include medical or dietary fields in prompts, and are instructed not to quote such values back in output.
• Safety and safeguarding are never withheld for non-payment. Whatever the state of the Club's subscription, including where a trial has ended or a subscription has lapsed, safeguarding, DBS and medical records remain readable and exportable, and the Club can always add to them: a DBS check, a training record, a health declaration or a consent can be recorded whatever the state of the subscription. That is a deliberate commitment. Incident and accident reporting is not yet part of Sail; when it arrives it will carry the same commitment.
• Retention of safeguarding records is the Club's decision and is often governed by its national governing body. We will not delete them on our own initiative.

8. Data about children

Sail holds records about under-18s. The Club is responsible for the consents it relies on and for its own safeguarding policy. We will not contact children directly, and our own marketing is directed at club officers.

9. Audits

We will make available the information needed to demonstrate compliance with Article 28. On request we will provide a written security summary, or complete a standard security questionnaire, which is normally sufficient for a club's own due diligence.

Where that is not sufficient, the Club may audit us, or appoint an independent auditor to do so, once in any twelve-month period, on at least 30 days' written notice, during business hours, without unreasonable disruption, and subject to confidentiality. The Club bears its own costs. More frequent audits may be carried out where required by a supervisory authority or following a personal data breach affecting the Club.

10. Deletion and return

While the subscription is active, the Club can export its data at any time, including while its dashboard is read-only.

When the agreement ends:

• the Club has 90 days to export its data;
• after that, we delete it or return it, at the Club's choice;
• we keep financial records for six years, where they form part of records we are required by law to retain, and for no other purpose. Six years is the standard UK retention period for business and tax records under the Companies Act 2006 and HMRC requirements. Data kept under this paragraph is retained in restricted form, is not used for anything else, and is deleted at the end of the period.
• The six-year period applies only to financial records. It is not a basis for keeping a membership database, including health and safeguarding information, and we do not do so.
• Backups are cycled on a rolling basis and data persists in them until overwritten. It is not restored into live use.

11. Liability

Each party's liability under this agreement is subject to the limitations in the Terms and conditions, except that nothing limits either party's liability where data protection law does not allow it, in particular compensation payable to a data subject under Article 82, or a fine imposed by the ICO.

12. General

• This agreement is governed by the law of England and Wales.
• If any part is unenforceable, the rest continues.
• It may be updated where data protection law changes or our processing changes. We will give notice as in section 5.

Annex A — Details of processing

Categories of data subject: club members including children; prospective members and applicants; parents and guardians; club officers and administrators; paid staff and instructors; volunteers; non-member customers such as course bookers, hire customers and day visitors; emergency contacts; witnesses named in incident reports.

Types of personal data

• identity and contact details: name, address, email, telephone, date of birth;
• membership records: category, status, joining and renewal dates, groups;
• emergency contact details;
• health, medical and dietary information where a member chooses to provide it, including where a member has chosen to share it with a defined group such as duty officers (special category, Article 9);
• DBS certificate details, safeguarding training records, safeguarding roles and clearance status (criminal offence data, Article 10);
• incident and accident reports, including the people involved, witnesses, and actions taken. These may describe injuries and so may include health data;
• waivers, declarations and parental consents;
• qualifications and instructor certifications;
• boats, sail numbers, equipment and insurance details;
• duty, rota, booking, event, course, hire, storage and race records;
• guest visits, day tickets and non-member records;
• payment records: amounts, dates, status and references. No card details: these go directly to Stripe and are never held by Sail;
• staff records: contracts, pay rates, shifts, leave, qualifications and timesheets;
• email correspondence, campaign records and communication preferences;
• exit surveys and feedback given when a member leaves;
• sign-in records, access logs and technical logs.

Annex B — Technical and organisational measures

Access control

• Sign-in by emailed link or password; sessions expire.
• Row-level security is enforced at the database layer on every table, so a club's data is inaccessible to any other club regardless of application behaviour.
• Section-by-section access lets a club restrict each person to the parts of the console they need. This is enforced by the application; the database enforces the club boundary and the role.
• Safeguarding records are visible to club administrators and committee members, to the person the record is about, and, for a junior, to their guardian. The database enforces this by role.
• Changes to a club's records are logged, with the person who made them. Reads are not logged, with one exception: every reveal of a staff member's National Insurance number or bank details is recorded individually.
• Our staff access to production systems is limited to those who require it for support or operations.

Encryption

• All traffic encrypted in transit using TLS.
• Data encrypted at rest by our hosting and database providers.

Data location

• The database is hosted in the United Kingdom.

Resilience and recovery

• Managed, automated database backups, retained and cycled by our database provider.
• Scheduled jobs are monitored, with missed runs detected and re-run.

Monitoring and error reporting

• Application errors are captured and monitored so faults are found by us rather than reported by a club.
• Our error monitoring is deliberately limited in what it receives. It is sent internal reference identifiers rather than names, email addresses or contact details. Sign-in details, request contents, cookies and network identifiers are removed before an error report is sent. Session recording is switched off, so nothing displayed on a club's screen is ever captured.
• Error reports are held in the European Economic Area.

Special category data

• Medical and dietary fields are excluded from AI prompts, and AI output is instructed never to quote them.
• Self-uploaded certificates do not count towards clearance until verified by an authorised person.

Organisational

• Everyone with access to personal data is bound by written confidentiality obligations.
• Access is granted on a need-to-know basis and revoked promptly when someone's role ends.
• We maintain a record of the sub-processors we use and where they process data.
• Changes to our own configuration that affect clubs are recorded and attributable to an individual.

Annex C — Sub-processors

The specific mechanism relied on for each provider is set out in that provider's own data processing terms, which we can supply on request.