Data Processing Addendum

This Addendum forms part of the Club Terms of Service and records the terms required by Article 28(3) of the UK GDPR. Where it conflicts with the Club Terms of Service on a data protection matter, this Addendum wins.

Where a clause exists because a specific provision of the UK GDPR requires it, that provision is named.

1. Definitions

"UK GDPR" and "Data Protection Law" mean the UK General Data Protection Regulation and the Data Protection Act 2018, together with any legislation replacing or amending them. "controller", "processor", "personal data", "processing", "data subject" and "personal data breach" have the meanings given in the UK GDPR.

"Club Data" means the personal data described in Annex 1, which the Club instructs Longroom to process on its behalf.

"Longroom" means Tim Hoare, a sole trader trading as Longroom, of 9 Ingram Road, London N2 9QA, as in the Club Terms of Service.

"Sub-processor" means a processor engaged by Longroom to process Club Data.

Other capitalised terms have the meanings given in the Club Terms of Service.

2. Who is controller, and of what

There are two categories of personal data in the Service, and the parties' roles differ between them.

2.1 Club Data: the Club is controller, Longroom is processor

The cricket records synced from Play-Cricket, described in Annex 1, are processed by Longroom on the Club's behalf and on its instructions. The Club decides that the sync should happen, supplies the Play-Cricket API token that makes it possible, holds the agreement with the ECB under which the data is available, and has its own relationship with the people the data is about. Longroom decides none of those things: it runs the sync the Club asked for and serves the results back to the Club's Members.

The Club is the controller of Club Data. Longroom is a processor of it. The rest of this Addendum sets out Longroom's obligations in that role.

2.2 Account and Service data: Longroom is controller

A Member's name, email address, sign-in identifiers, conversations with the assistant, usage records, error logs and notification tokens are not processed on the Club's instructions. A Member creates an account with Longroom directly, Longroom decides what is collected and why, and Longroom answers to that Member for it.

Longroom is the controller of that data. It is described in the Privacy Policy, and this Addendum does not apply to it. The Club is not responsible for it, and cannot instruct Longroom about it.

One thing that can look like an instruction is not one. A Member's account exists at the Club's discretion: that is a rule Longroom sets as controller and tells Members in the Member Terms of Use, and it is why the Club's administrators can suspend or remove a Member from the app. When they do, the Club is deciding who is in the Club; what then happens to the account — a suspended account is kept, a removed one is deleted — is Longroom's own rule, applied to its own data. Any note an administrator records against a suspension or a bar is personal data about that Member, which Longroom holds as controller and which the Member can ask Longroom for; the Club should keep such notes factual and about the Member.

2.3 Content derived from Club Data

The two categories meet in one place. A Member's question to the assistant is Longroom's data as controller, but the answer is derived from the Club's data. Where content derived from Club Data is stored inside a conversation, Longroom treats that content as Club Data and applies this Addendum to it. Where the Club exercises a right under this Addendum over Club Data, such as deletion at the end of the agreement, Longroom applies it to that derived content too.

Neither party is a joint controller with the other. Each is separately responsible for the category it controls.

2.4 The ECB

The ECB operates Play-Cricket and is a controller of the data held in it, independently of both parties. Nothing in this Addendum affects the ECB's role or the Club's agreement with it.

3. The Club's obligations as controller

The Club:

1. confirms that it has a lawful basis under Article 6 of the UK GDPR for the processing it instructs, and where any special category data is involved, a condition under Article 9;
2. confirms that it has given the people the data is about the information required by Articles 13 and 14, by way of its own privacy notice to its members, and that this notice covers the use of a third-party service to produce statistics from Play-Cricket records;
3. is responsible for the accuracy and lawfulness of the Club Data and of its instructions; and
4. will not instruct Longroom to process personal data beyond what is described in Annex 1 without agreeing it with Longroom first.

4. Longroom's obligations as processor

The obligations in this clause are the ones Article 28(3) requires.

4.1 Processing only on documented instructions (Article 28(3)(a))

Longroom will process Club Data only on the Club's documented instructions, including in relation to transfers outside the UK, unless UK law requires otherwise. If UK law does require otherwise, Longroom will tell the Club before processing, unless the law forbids it from doing so.

The Club's documented instructions are: this Addendum, the Club Terms of Service, the configuration the Club sets in the Service, and any further written instruction the Club gives. The ordinary operation of the Service, meaning syncing from Play-Cricket, storing, indexing, serving statistics to Members, answering Members' questions and taking backups, is instructed by this Addendum.

Longroom will tell the Club immediately if, in its opinion, an instruction infringes Data Protection Law.

Longroom does not use Club Data for its own purposes. In particular it does not sell it, does not use it to market to anyone, and does not use one club's data to serve another club. Aggregate operational counts that identify nobody, such as how many questions were asked in a month and how long answers take, are used to run and improve the Service.

Longroom does not use Club Data to train or fine-tune any machine learning model, and will not do so unless the Club instructs it in writing. Anthropic, the only sub-processor that receives Club Data as an input to a model, does not train on it either; Annex 3 records that.

4.2 Confidentiality (Article 28(3)(b))

Longroom is currently operated by one individual, Tim Hoare, who is bound by the confidentiality obligations in this Addendum and the Club Terms of Service. Any person Longroom later authorises to process Club Data will be bound by a written confidentiality undertaking of at least equivalent effect before being given access.

4.3 Security (Article 28(3)(c) and Article 32)

Longroom will implement appropriate technical and organisational measures to protect Club Data, taking account of the state of the art, the cost of implementation, and the nature, scope and risks of the processing. The measures in place are set out in Annex 2.

4.4 Sub-processors (Articles 28(2) and 28(4))

The Club gives general authorisation to Longroom to engage the Sub-processors listed in Annex 3.

If Longroom intends to add or replace a Sub-processor for Club Data, it will give the Club's administrators at least 30 days' notice by email. If the Club reasonably objects on data protection grounds within that period, the parties will discuss it in good faith; if no resolution is reached, the Club may terminate the Club Terms of Service without penalty and receive a pro-rata refund of any period paid for and not used.

Longroom will impose on each Sub-processor, by written contract, data protection obligations materially equivalent to those in this Addendum, and remains fully liable to the Club for a Sub-processor's failure to meet them.

4.5 Assisting with data subjects' rights (Article 28(3)(e))

If a person exercises a right under Chapter III of the UK GDPR, meaning access, rectification, erasure, restriction, portability or objection, in relation to Club Data:

• Longroom will not respond to the request itself unless the Club instructs it to, and will pass the request to the Club's administrators without undue delay, and in any event within 5 working days of recognising it;
• Longroom will provide reasonable assistance, by technical measures where possible, to let the Club respond within the statutory period.

The Service already provides export and deletion for a Member's own data, which handles most requests without either party having to do anything.

Assistance under this clause is provided at no charge, unless a request is manifestly unfounded, excessive or repetitive, in which case Longroom may charge its reasonable costs after telling the Club what they will be.

Complaints are a separate duty from rights requests. Since 19 June 2026 a controller must provide a route for data protection complaints, acknowledge one within 30 days, investigate it and communicate the outcome. That duty falls on the Club for Club Data. Where a complaint about Club Data reaches Longroom, Longroom will pass it to the Club's administrators without undue delay and within 5 working days, on the same basis as a rights request, and will provide the information the Club needs to investigate it. Longroom operates its own complaints route for the data it controls, described in the Privacy Policy.

4.6 Assisting with security, breaches and impact assessments (Article 28(3)(f))

Longroom will provide reasonable assistance to the Club with its obligations under Articles 32 to 36, taking account of the nature of the processing and the information available to Longroom. In particular:

Personal data breaches. Longroom will notify the Club's administrators of a personal data breach affecting Club Data without undue delay after becoming aware of it, and in any event within 24 hours of becoming aware. The notification will describe, so far as Longroom knows at the time: what happened, the categories and approximate number of data subjects and records affected, the likely consequences, and the measures taken or proposed. Longroom will keep the Club updated as more becomes known.

The 24-hour commitment exists so that the Club can meet its own 72-hour obligation to the ICO under Article 33. The Club, as controller, decides whether to notify the ICO or affected individuals; Longroom will not do so on the Club's behalf.

The limits of detection. That clock starts when Longroom becomes aware of a breach. Longroom monitors for operational failure such as a broken sync or a token that no longer works, and it logs authentication events — sign-ins, failed sign-ins, refresh-token replay and administrator actions — and alerts its operator on the patterns that suggest unauthorised access, as described in Annex 2. Detection is still bounded: most of those alerts are raised by a nightly check rather than in real time, there is no 24/7 monitoring, and an access that presents valid credentials and triggers none of the alerted patterns may not be detected promptly or at all. The Club should weigh the notification commitment against those limits.

Impact assessments. Longroom will provide the information the Club reasonably needs for a data protection impact assessment or prior consultation under Articles 35 and 36.

4.7 Deletion or return at the end (Article 28(3)(g))

On the end of the Club Terms of Service, at the Club's choice, Longroom will delete or return all Club Data, and delete existing copies, unless UK law requires it to be retained.

In practice:

• The Club's cricket records remain in Play-Cricket throughout, under the Club's own account and independently of Longroom. That is the Club's primary route to its own data and it does not depend on this clause.
• For 30 days after the agreement ends, the Club may request an export of the cricket records Longroom holds for it, and Longroom will provide one in a common machine-readable format. This is the "return" option. The Club's administrators can also download the same export themselves from the Service, and a suspension of the Club's access does not remove it. It covers the Club's records and not Longroom's database schema or queries, which clause 6A of the Club Terms of Service leaves with Longroom.
• After that 30 days, Longroom deletes the Club Data from the live Service, unless the Club has asked in writing for longer. Deletion is a single reviewed operation carried out by Longroom under a documented offboarding procedure.
• Backups are deleted on their own rotation and Club Data will have left all backups within 13 months of live deletion. Backup copies are not restored to the Service and are not processed for any purpose in the meantime. That period is when deletion completes rather than an exception to it.

Where Longroom must retain something because the law requires it, such as a record needed for tax or to establish or defend a legal claim, it will tell the Club what and why, and will process it for no other purpose.

4.8 Information and audit (Article 28(3)(h))

Longroom will make available to the Club all information reasonably necessary to demonstrate compliance with this Addendum and with Article 28, and will allow and contribute to audits and inspections by the Club or an auditor it appoints.

Given the size of the Service, that will normally be satisfied by Longroom answering the Club's written questions and providing the documents it holds. The Club may also, on 30 days' notice, not more than once in any 12 months unless there has been a breach affecting Club Data or the ICO requires it, carry out a fuller audit. An audit must be during business hours, must not unreasonably disrupt the Service, must respect other clubs' confidentiality, and is at the Club's cost, except where it reveals material non-compliance, when Longroom bears the reasonable cost.

5. International transfers

Club Data is stored in the United Kingdom or the European Economic Area.

Two transfers outside that area are inherent in the Service, and by agreeing to this Addendum the Club instructs Longroom to make them:

• The assistant sends the text of a Member's question, the conversation so far, and data retrieved from the Club's database in order to answer it, to Anthropic in the United States. Without that transfer the assistant cannot work.
• Push notifications are delivered through Google's Firebase Cloud Messaging and, for iPhones, Apple's Push Notification service, both in the United States. A notification can name a player — a debut, a milestone — as well as teams and results. It is sent only to Members who have turned notifications on, and only for the events they have chosen; those services hold the message in order to deliver it and for nothing else.

For Anthropic, Longroom relies on the UK International Data Transfer Addendum to the EU Standard Contractual Clauses, which is incorporated into Anthropic's data processing addendum and applies to Longroom's use of the API. For Google and Apple, Longroom relies on the safeguards recorded in Annex 3. Longroom will maintain an appropriate safeguard under Article 46 for as long as each transfer continues, and will tell the Club if a mechanism changes.

Longroom will not transfer Club Data outside the UK or EEA other than as described here without the Club's prior written instruction.

6. Liability

Each party's liability under this Addendum is subject to the limits in clause 10 of the Club Terms of Service, including the cap in clause 10.3. This Addendum does not displace that cap, and the precedence rule at the top of this Addendum does not operate to disapply it.

Nothing in either document limits or excludes either party's own liability to a data subject under Article 82 of the UK GDPR. Article 82 gives data subjects rights directly against a controller and against a processor, and no agreement between the parties can affect them.

Regulatory fines are each party's own. A fine or other penalty imposed on a party by the Information Commissioner is that party's to bear. Neither party indemnifies the other against its own fine, and any claim by one party against the other in respect of a fine is subject to the cap in clause 10.3 like any other claim. Neither party gives an uncapped regulatory indemnity.

7. General

This Addendum takes effect when the Club Terms of Service do, and continues for as long as Longroom processes Club Data.

It is governed by the law of England and Wales, and the courts of England and Wales have exclusive jurisdiction.

If a change in Data Protection Law, or guidance from the ICO, means this Addendum no longer meets what the law requires, the parties will agree in good faith the changes needed to make it do so.

---

Annex 1: What is processed

Article 28(3) requires the subject-matter, duration, nature and purpose of the processing, the types of personal data, and the categories of data subject to be set out.

Subject-matter. Provision of the Longroom service to the Club: syncing the Club's Play-Cricket records, storing and organising them, and making statistics and answers about them available to the Club's Members.

Duration. For the term of the Club Terms of Service, plus the deletion periods in clause 4.7.

Nature of the processing. Collection by API from Play-Cricket; storage in a database dedicated to the Club; organisation, structuring and derivation of statistics; retrieval by database query, including queries composed by a language model; disclosure to the Club's Members through the Service, including in push notifications to Members who have turned them on; transmission to the sub-processors in Annex 3; backup; and erasure.

Purpose. Producing cricket statistics and answering questions about the Club's own cricket records, for the Club and its Members. No other purpose.

Categories of data subject.

• Players who have appeared for the Club, across every season the Club's Play-Cricket records cover, including former members and, in respect of junior cricket, children. How far back that goes differs from club to club; the Club's own first season is configured when the Club is set up.
• Club officials recorded in match records: captains, wicketkeepers, scorers and umpires.
• Players who have appeared for opposing clubs in matches against the Club.

Types of personal data.

• Name, and the Play-Cricket player identifier.
• Match participation: which matches a person played in, for which team, on what date, at which ground.
• Performance records: runs, balls faced, dismissals, bowling figures, catches, stumpings, run-outs, partnerships.
• Roles held in a match: captain, wicketkeeper, and where recorded, official.

What is deliberately not processed. The sync does not collect, store or use dates of birth, postal addresses, telephone numbers, email addresses, photographs, or guardian details for under-16s, although Play-Cricket holds them. Data collection is limited to what is needed to produce cricket statistics.

This is about Club Data. A Member's own email address is held by Longroom as controller, to create the account and to sign the Member in: it comes from the Member, not from Play-Cricket, it is not part of Club Data, and clause 2.2 governs it.

No special category data is knowingly processed as Club Data. If the Club were to introduce any, in a team name for example, it would be doing so outside the intended use of the Service. The one free-text field a Club administrator can write in the Service, the note against a Member's suspension or bar, is account data under clause 2.2 rather than Club Data; clause 2.2 asks the Club to keep it factual and about the Member, and a safeguarding note may nonetheless amount to criminal-offence data under Article 10, which is why it is disclosed to the Member and provided to them on request.

Opposition players

Club Data includes the names and performance records of players from other clubs. Those people are not the Club's members and have no relationship with Longroom.

The position taken is that this data is match-participation information already published by the ECB on Play-Cricket, that both parties process it for the narrow and expected purpose of recording the results of matches that were played, and that this is within the reasonable expectations of anyone who plays club cricket in a league whose scorecards are published. The Club, as controller, is responsible for satisfying itself that it has a lawful basis, most likely legitimate interests supported by a legitimate interests assessment, and that Article 14 is met or an exemption applies.

This position is recorded here rather than assumed.

Annex 2: Technical and organisational measures

Article 32. These are the measures in place.

Access control.

• The Service is invite-only. A person cannot see any club's data without being invited by that club or holding its join code.
• Sign-in is by Google, Apple, or an emailed single-use link. Longroom stores no passwords.
• Sessions use signed tokens in secure, HTTP-only cookies, with a rotating refresh token.
• Administrative functions are restricted to administrators of the club concerned.
• Server access is restricted to Longroom's operator, over SSH with key-based authentication only.

Separation of clubs.

• Each club's cricket data is held in a separate database file, not in shared tables distinguished by an identifier. Every request is resolved to one club before data is read.
• Application data that is shared between clubs, such as accounts and conversations, carries a club identifier which is enforced on every query.

Encryption.

• All traffic between users and the Service is encrypted with TLS.
• Play-Cricket API tokens and language model API keys are held encrypted at rest with Fernet (AES-128-CBC with HMAC-SHA256), under a key held outside the database.
• The database files are held on a volume encrypted at rest with LUKS full-volume encryption. This protects against storage media leaving the provider's custody, disk disposal, and copies of the volume itself. It does not protect against a compromise of the running server, where the volume is unlocked; and the unlock key is held on the server's own boot disk so that the Service can restart unattended, so it does not protect against an attacker who obtains the contents of both disks together.
• Backups are encrypted before they leave the server (age, X25519 public-key encryption, file by file) and transferred over SSH, so the off-site copies are held encrypted at rest and the off-site storage credential alone does not give access to Club Data. The private key needed to read a backup is held on the server's boot disk, for the routine restore test, and separately outside the server; it has the same limit as the volume key above — it does not protect against a compromise of the running server.

Integrity.

• The cricket database is opened read-only on the serving path. Nothing a Member does can alter the Club's cricket records.
• Queries composed by the language model are parsed and rejected unless they are a single read-only statement, and are executed against a read-only connection. Results are capped at 200 rows before they reach the model. There is no execution timeout.

Resilience and recovery.

• Nightly backups of the application database and each club's cricket database, taken as consistent snapshots, transferred off-site to separate storage.
• Retention: seven daily backups and twelve monthly backups.
• The cricket data can also be rebuilt from Play-Cricket, which is an independent recovery path and in practice the strongest one.
• Restores are tested routinely: each week the most recent backup is restored into an isolated scratch area, decrypted and checked — that it is encrypted, that it decrypts, database integrity, and the presence of each club's data. A nightly check alerts the operator to a failed test, to the test not having run, or to the backup itself having gone stale.

Monitoring.

• Automated nightly checks of each club's sync, alerting the operator by email to a stale sync, a failing token, or other defined failures.
• Application error logging, reviewed by the operator.
• Authentication-event logging: sign-ins, failed sign-ins, refresh-token replay and administrator actions are recorded with the IP address and browser identifier of the request, and retained for 90 days.
• Reuse of a session refresh token revokes the whole session family automatically and alerts the operator immediately.
• A nightly check alerts the operator to a burst of failed sign-ins against a club, and summarises administrator activity.

Organisational.

• One individual has access to production systems and to Club Data.
• No secret is committed to the code repository in the clear. The Service's production configuration (API keys, the key that protects the encrypted tokens above, and the backup settings) is held in the repository only in encrypted form (age, X25519 public-key encryption) and is decrypted on the server, and by the operator. The server's decryption key is held on its boot disk so that the Service can restart unattended, and separately outside the server; it has the same limit as the volume key above.
• Changes are reviewed before deployment.

What Longroom does not have.

• No ISO 27001 or SOC 2 certification, and no independent penetration test.
• No 24/7 monitoring or on-call rota, and no formal business-continuity certification.
• No real-time intrusion detection beyond the authentication alerting above. The burst check runs nightly, not continuously; there is no network-level monitoring and no detection of location anomalies; and an access using valid credentials that triggers none of the alerted patterns leaves only the sign-in log. Clause 4.6 sets out what this means for breach notification.
• The database volume encryption, the backup encryption and the configuration encryption described above have the stated limits: none defends a compromised running server, and all three keys live on the same server's boot disk.

These measures are proportionate to a small service processing cricket scores that are already published. The Club should judge them against its own risk appetite rather than assume an enterprise posture.

Annex 3: Sub-processors

Sub-processors of Club Data. These process personal data that the Club controls.

Other recipients, where Longroom is the controller. Listed for completeness. They do not receive Club Data and are governed by the Privacy Policy rather than this Addendum.

Map tiles are not a recipient. The grounds map's imagery is served by Longroom from Longroom's own servers, which fetch and cache it from OpenStreetMap. A Member's browser makes no request to any map provider. OpenStreetMap receives requests from Longroom for map squares, and no personal data.

Transfers to the sub-processors and recipients above outside the UK rely on the UK International Data Transfer Addendum to the EU Standard Contractual Clauses, or on the UK extension to the EU-US Data Privacy Framework where the recipient is certified under it. For Google, the Firebase data processing terms apply, and Google is certified under that UK extension. Apple is the exception: the notification service is provided under the Apple Developer Program licence terms, Apple is not certified under the UK extension, and the safeguard for that transfer is under review — clause 4.4's notice applies to whatever resolves it.

Longroom will update this Annex when it changes, and will give notice under clause 4.4 before adding or replacing a Sub-processor of Club Data.