Data processing addendum

1. What this is, and who it is for

This addendum is for coaching organisations — academies, clubs and their administrators. If you are an athlete, a parent or a coach using an account your organisation gave you, the document you want is the Privacy notice; this one describes the contract behind it.

The processor under this addendum is PerfHQ LTD, a company registered in England and Wales under company number 17471470, whose registered office is 167-169 Great Portland Street, 5th Floor, London, W1W 5PF. The controller is your organisation, subject to section 2.

It forms part of the Terms of Service and sets out the terms required by Article 28 of the UK GDPR, which govern our processing of personal data on your instructions. Where it conflicts with the Terms of Service on a data protection matter, this addendum wins.

Defined terms — controller, processor, personal data, special category data, processing, data subject, personal data breach, supervisory authority — carry the meaning given to them in the UK GDPR.

2. Who is controller of what

The practical consequence of the second card is that you cannot instruct us to delete a person's medical record from your organisation alone while they remain a member elsewhere, and you should not tell a data subject that you can.

3. What is processed

Please read that list twice before agreeing to it. It is children's health data, and processing it at scale alongside systematic recording of physical movement is exactly the combination that makes a data protection impact assessment mandatory under Article 35. That obligation is yours as controller for your own processing, and section 9 sets out what we will do to help.

4. Our obligations

We will:

• process personal data only on your documented instructions, which the Terms of Service and your configuration of the service constitute, unless we are required to do otherwise by law — in which case we will tell you first, unless the law forbids it;
• ensure that anyone authorised to process the data is under an appropriate duty of confidentiality;
• implement the technical and organisational measures described in section 5;
• respect the sub-processor conditions in section 6;
• assist you with data subject requests, to the extent described in section 8;
• assist you with your obligations under Articles 32 to 36, to the extent described in section 9;
• delete or return the data as described in section 10;
• make available the information needed to demonstrate compliance, and submit to audits as described in section 11.

We will tell you if, in our opinion, an instruction you give us infringes data protection law.

4a. Your obligations as controller

You are the controller for the coaching data described in section 2, and the decisions below are yours alone. PerfHQ provides the tools; it does not make any of these choices for you and is not in a position to check them.

You warrant that, for all personal data you or your members put into PerfHQ:

• You have a lawful basis under Article 6, and a condition under Article 9 for the health data — medical notes, allergies, conditions, medications and dietary requirements — that the service invites you to record.
• You have given your athletes and their guardians the information Articles 13 and 14 require, including that PerfHQ processes the data on your behalf. Our privacy notice describes what we do; it is not, and cannot be, your notice to the people you coach.
• You have obtained consent from a person with parental responsibility before entering a child's information, and before filming or photographing them. Recording a consent decision in PerfHQ is your note of a decision made elsewhere — it is not the obtaining of consent, and the software does not check every route by which media can reach it. Section 4 of the Safeguarding and media consent policy sets out precisely where the consent gate applies and where it does not; read it before relying on it.
• The data is accurate and no more than you need, and you keep it that way.

You are also responsible for:

• Who you give access to. You decide who administers your organisation, which coaches hold the medical permission, and which hold the internal-notes permission. A permission granted too widely is a decision, not a defect.
• Your staff. Safeguarding, recruitment and DBS checks, your code of conduct, and what your coaches write into notes and feedback.
• Your members' content. You are the first line of moderation for what your people upload, using the reporting queue, the 24-hour action window and the block described in section 6 of the Terms of Service. PerfHQ acts as a backstop where you do not; that backstop does not transfer the responsibility to us.
• Keeping an administrator reachable, so that a breach notification or a data-subject request from us reaches a person who can act on it.

Indemnity. You will indemnify PerfHQ against claims, regulatory fines and reasonable costs arising from your breach of this section — in particular a missing lawful basis or Article 9 condition, a missing or exceeded parental consent, content your members upload, or access you granted. This does not apply to anything caused by our own breach of this addendum, our security obligations under section 5, or our own negligence.

What this section cannot do, and why it does not try

An allocation of responsibility is only worth having if it is accurate, so it is worth being plain about the limits — an addendum that over-reaches is evidence against the party that drafted it rather than protection for them.

• Some duties sit on a processor directly and no contract moves them. Security of processing (Article 32), breach notification to you (Article 33(2)), and answering for our sub-processors (Article 28(4)) are ours because the Regulation puts them there.
• A data subject can claim against either of us under Article 82, whatever we have agreed between ourselves. The indemnity above decides who ultimately pays; it does not stop the claim landing.
• We are controller for the identity data in section 2, because we decided to share medical notes and emergency contacts across every organisation a person belongs to. Article 28(10) is explicit that a processor determining purposes and means becomes a controller for that processing, so calling it something else in a contract would not make it so.
• App store obligations are not yours to carry. Apple holds the developer responsible for moderating user-generated content, regardless of who the developer's customers are. PerfHQ learned this the expensive way: the product once assigned moderation to the tenant and built no tools, which assigned it to nobody, and the app was rejected under guideline 1.2.
• Liability for death or personal injury caused by negligence, and for fraud, cannot be excluded at all (UCTA 1977).

5. Security

The measures below are the ones actually in place. They are stated specifically rather than as a general assurance, because a general assurance is not something you can assess.

• Passwords are stored using Argon2id (m=64MB, t=3, p=4) and are never recoverable in readable form. Password reuse is prevented against previous hashes, and password policy is configurable per organisation.
• Session and reset tokens are stored only as SHA-256 digests, so a copy of the database yields no usable session. Refresh tokens rotate on use, and reuse of a rotated token is detected and revokes the session.
• Two-factor secrets are encrypted with AES-256-GCM under a key held outside the database. The service refuses to start in production without that key. Time-based codes are single-use.
• Access tokens are RS256-signed, last ten minutes, and are validated against a published key set.
• Authorisation is permission-based rather than role-based, and is enforced on the server. Tenant isolation is applied by a database-level query filter rather than by each query remembering to. Medical and emergency information sits behind its own permission, and internal coaching notes are excluded from an athlete's and a guardian's view before any permission check runs.
• Media is stored in private object storage and served only through short-lived, media-scoped signed URLs.
• In transit, all traffic is encrypted with TLS. Administrative access to the servers is restricted to a private network.
• Audit records are kept of changes to significant records, including who made them.
• Backups are taken automatically and stored separately from the primary database.

Two limits you are entitled to know about before you sign. We do not apply our own encryption at rest on top of what the hosting provider offers, so the relevant threat — an insider at the hosting provider reading the database — is not addressed by us. And a full restore from backup has not yet been rehearsed; an unrehearsed backup is a hypothesis rather than a control. Both are recorded openly in our internal data classification, and both are stated here rather than papered over.

6. Sub-processors

You give general written authorisation for the sub-processors below. We impose data protection obligations on each of them no less protective than those in this addendum, and we remain fully liable to you for their performance.

Nobody else. There is no analytics provider, no advertising network, no error-tracking service, no payment processor, no SMS provider and no artificial intelligence or machine learning service in this list, because there is none in the product. The iOS app contains no third-party code of any kind.

Changes. We will give you at least 30 days' notice before adding or replacing a sub-processor. If you reasonably object on data protection grounds within that period, we will discuss it with you, and if we cannot resolve it you may terminate without penalty for the affected part of the service.

International transfers. We cannot currently state that all personal data remains within the UK or EEA, because the Cloudflare network is global and the IONOS datacentre region is still being confirmed. Where a transfer outside the UK occurs it is made under the UK International Data Transfer Addendum to the EU Standard Contractual Clauses, or another lawful transfer mechanism. We would rather tell you this than claim a guarantee we have not verified, and we will update this section when the region is pinned.

7. Personal data breaches

We will notify you without undue delay after becoming aware of a personal data breach affecting personal data we process for you, and in any event within 48 hours. The notification will describe the nature of the breach, the categories and approximate number of data subjects and records affected, the likely consequences, the measures taken or proposed, and a contact point.

Deciding whether to notify the ICO and the affected data subjects is yours as controller, because the assessment turns on facts you hold. We will give you what you need to make it, and will not make a public statement about a breach affecting your data without consulting you first, unless the law requires us to.

We treat a breach involving a child's health data or media as the most serious category of incident we can have, and will handle it accordingly.

8. Data subject requests

We will notify you without undue delay if a data subject contacts us directly with a request concerning data we process for you, and we will not respond to it ourselves except to acknowledge it and direct them to you — unless we are the controller for the data in question, as set out in section 2.

We will assist you in responding, taking into account the nature of the processing. What we can do today, honestly stated:

• We can produce an automated export of a person's identity, medical information, emergency contacts, guardian links, organisation memberships, recent sign-in attempts and active sessions. It excludes credentials and lists them as withheld.
• That export does not yet cover the coaching platform. Feedback, bookings, assessment results, coach notes and media are held in tables the export does not reach. We will gather them by hand on request, and the export itself says so rather than implying completeness.
• We can delete a person's account, or their membership of your organisation, self-service or on request.
• Erasure is not yet complete. Some coaching records cannot be removed automatically because performance data depends on them; in those cases the internal reference is kept and the identity detached from it, so the record no longer resolves to a person. Our change-audit trail keeps the fact of a change, by whom and when, for seven years; the previous values it held about that person are cleared at the point of erasure. We will tell any individual specifically what remains for them.
• Guardian access cannot yet be withdrawn through the product before the child turns 18. We will do it by hand on request.

Those four limits are why this section is longer than it would otherwise be. You will be relying on them when you answer a subject access request, so you need them accurately rather than optimistically.

9. Impact assessments and prior consultation

Taking into account the nature of the processing and the information available to us, we will provide reasonable assistance with your data protection impact assessments and any prior consultation with the ICO. In practice that means giving you the description of processing, the security measures and the sub-processor list you need, and answering questions about how the software works.

We will say plainly what we cannot do: we cannot write your DPIA, and we cannot assess a risk that depends on how your organisation coaches, who your coaches are, or what you tell parents.

10. Deletion and return

On termination, or on your written instruction, we will delete the personal data we process for you, subject to section 8's limits on erasure and to any retention required by law. You may request a copy before deletion; ask before you terminate, because deletion is not reversible and support cannot restore it.

Retention periods that operate while the service is running are published in section 8 of the Privacy notice. Two are worth flagging here because they are your decision rather than ours: media has no automatic expiry unless you set one, and by default none is set, and items in the trash are purged after 30 days.

11. Audit

We will make available the information reasonably necessary to demonstrate compliance with this addendum, and will contribute to audits conducted by you or an auditor you appoint. Audits must be on reasonable notice, no more than once a year unless there has been a breach or a regulator requires it, during business hours, subject to confidentiality, and conducted so as not to disrupt the service or compromise the confidentiality of other organisations' data.

12. Liability, transfer and general

The liability provisions in section 10 of the Terms of Service apply to this addendum, except that nothing in it limits either party's liability to a data subject under Article 82 — a data subject may claim against either of us regardless of how we have allocated responsibility between ourselves. An indemnity decides who ultimately pays; it does not stop the claim landing.

Your indemnity to us is in section 4a. It is not capped by the fee limit in section 10 of the Terms, because that limit measures what we earned from you and the harm it would answer for is harm to a child whose data you entered without a basis to.

Transfer. We may transfer, assign or novate this addendum to a successor entity — including on a reorganisation or a sale of the PerfHQ business — on notice to you, provided that entity assumes the same obligations. This is here deliberately: a change in the corporate vehicle behind PerfHQ should not require every organisation to re-paper its contract.

This addendum is governed by the law of England and Wales.

13. Contact

Data protection matters, including anything in this addendum: privacy@perfhq.com.

PerfHQ is a trading name of PerfHQ LTD, a company registered in England and Wales under company number 17471470. Registered office: 167-169 Great Portland Street, 5th Floor, London, W1W 5PF.