Data Processing Agreement

Subject matter

Hosting and processing worker tip records in Fairpool so the Customer can allocate tips.

Duration

The term of the Terms of Service, then until Customer Personal Data is deleted under section 8 of this agreement.

Nature

Collecting, recording, storing, calculating, displaying, exporting, anonymising and deleting data entered by the Customer, and showing workers their own records through private links the Customer issues.

Purpose

Allocating tips, gratuities and service charges fairly and keeping the records the Employment (Allocation of Tips) Act 2023 requires.

Types of personal data

Worker names; roles and role weights; employment type (employee or agency worker) and, for agency workers, the agency's name; hours worked by date; tips, allocations, tip shares, pay-by and paid dates; corrections and top-ups with their notes and references; workers' requests for their records, with dates, replies and notes; tip notes; the tipping policy, its past versions and consultation summaries, which may name workers; whether a private record link exists, when it was issued, and when it was opened with the IP address used; and change-log entries linked to workers.

Special category and criminal offence data

None is needed or intended. The Customer must not enter any (section 2), so Fairpool processes none on the Customer's instructions.

Data subjects

The Customer's current and former workers, including employees and agency workers, some of whom may be aged 16 or 17, and anyone named in the Customer's tipping policy or consultation summaries.

Fairpool processes Customer Personal Data only on the Customer's documented instructions, including on transfers outside the UK, unless UK law requires otherwise (in which case Fairpool will tell the Customer first unless the law forbids it). The Terms of Service, this agreement and the Customer's use of Fairpool's features are the Customer's instructions. Fairpool will tell the Customer straight away if it thinks an instruction breaks data protection law.

The Customer must have a lawful basis for the data it enters, tell its workers about it, and enter only what it needs. It must not enter special category data (such as health, ethnic origin, religion, trade union membership, sex life or sexual orientation) or criminal offence data in any free-text field: tip notes, record-request notes, correction notes and references, the tipping policy or consultation summaries. If it employs workers under 18, it must take their age into account in what it records and who it gives private links to.

Only Callum Pollard and any staff or contractors Fairpool engages who need access to run the service may access Customer Personal Data, and each is bound by a duty of confidentiality.

Fairpool takes the technical and organisational measures Article 32 requires, appropriate to the risk. The current measures are in the Schedule below. Fairpool may change them only if the overall level of protection is not reduced.

The Customer gives general written authorisation for Fairpool to use the sub-processors listed on the sub-processors page and the providers they use.

• Fairpool's own changes. Fairpool will email the Customer's owners at least 30 days before it adds or replaces a sub-processor of Customer Personal Data.
• Changes by a sub-processor. Our sub-processors give us shorter notice when they change their own providers (Render Services, Inc.: 10 days; Plus Five Five, Inc. (trading as Resend): 14 days), so Fairpool cannot give 30 days for those. Fairpool will email the Customer's owners within 2 working days of receiving such a notice, and the sub-processors page links to each provider's own list.
• Urgent replacements. If a sub-processor must be replaced at short notice to protect Customer Personal Data or keep the service running, for example because it has failed or had a security incident, Fairpool will tell the Customer as soon as it can, before the change if possible.

Objecting. The Customer may object to any change on reasonable data protection grounds by emailing privacy@fairpool.example within 30 days of our notice. Fairpool will discuss the objection in good faith. All customers share the same providers, so if we cannot resolve it, the Customer may end the Terms of Service by notice and receive a refund of fees paid for any period after it ends.

Fairpool will impose data protection obligations on each sub-processor equivalent to those in this agreement, and remains liable to the Customer for its sub-processors' performance.

Fairpool gives the Customer tools to respond to requests from workers: viewing and correcting a worker's details, exporting everything held about a worker as a file, marking a worker as no longer working at a venue (which stops new hours and their private link while keeping their records), and erasing or anonymising a worker. If a worker contacts Fairpool directly, Fairpool will pass the request to the Customer without undue delay and will not respond itself except to say it has done so.

Fairpool has no separate control to restrict processing (Article 18). If a worker asks the Customer to restrict their data, the Customer can mark them as no longer working at the venue and stop using their records except to store them. If the Customer needs more, Fairpool will help by hand on written request to privacy@fairpool.example. Fairpool will give any further reasonable help the Customer needs.

Taking into account the nature of the processing and the information available to it, Fairpool will help the Customer meet its obligations under Articles 32 to 36 of the UK GDPR: security, notifying personal data breaches to the ICO and to workers, data protection impact assessments and prior consultation with the ICO. Fairpool may charge reasonable costs for help beyond providing information it already has.

While the Terms are in force, Fairpool deletes records automatically on the schedule below, and the Customer can export or delete data at any time. When the Terms end, the Customer can export its data first. Fairpool then deletes all Customer Personal Data 90 days after they end, or, if a notice under the Terms went late, once 7 days have passed since the final notice, unless UK law requires it to keep a copy. Deleted data leaves the hosting provider's point-in-time recovery within 7 days, and any independent backup (see the Schedule) within 30 days. On request, Fairpool will confirm deletion in writing.

Fairpool will make available all information needed to show it complies with Article 28 and this agreement. It will allow audits, including inspections, by the Customer or an auditor the Customer appoints who is bound by confidentiality, on at least 30 days' notice, no more than once a year unless there has been a personal data breach or a regulator requires it. Fairpool may first offer written answers and documents; the Customer pays its own audit costs.

Customer Personal Data is stored in Frankfurt, Germany (EU region). The hosting provider and the email provider are US companies, so using them is a transfer to the US even where the servers are in Europe. The Customer authorises these transfers on the safeguards shown for each provider on the sub-processors page: the UK Extension to the EU–US Data Privacy Framework (the UK–US data bridge), backed by the UK International Data Transfer Addendum to the EU Standard Contractual Clauses in the provider's own terms. Fairpool will not transfer Customer Personal Data anywhere else unless UK adequacy regulations or appropriate safeguards under Article 46 of the UK GDPR cover the transfer.

Fairpool will notify the Customer without undue delay after becoming aware of a personal data breach affecting Customer Personal Data, and aims to do so within 48 hours, so the Customer can meet its own 72-hour deadline to report to the ICO. The notice will describe, as far as Fairpool then knows, what happened, the categories and approximate numbers of workers and records affected, the likely consequences, and the steps taken or proposed. Fairpool will send further details as they become available and take reasonable steps to contain the breach.

Liability under this agreement is subject to the limits in the Terms of Service, which do not affect workers' own rights under data protection law. If this agreement conflicts with the Terms on data protection, this agreement wins. The law of England and Wales governs it.

Access and accounts

• Passwords are stored only as bcrypt hashes. Failed sign-ins take the same time whether or not the email exists.
• Owners and admins must use two-factor authentication, and an organisation can require it for everyone. Two-factor secrets are encrypted at rest and recovery codes are stored only as hashes.
• Sign-in sessions use 256-bit random tokens. Only a SHA-256 hash of each token is stored. The cookie is HttpOnly, Secure, SameSite=Lax and host-only. A session ends after 30 minutes without activity and at most 12 hours after sign-in. Users can sign out of every device, and a password reset signs out every session.
• Password reset links are single-use, stored only as a hash, and expire after 30 minutes. Emailed links use a fixed site address, never one taken from the request.
• Rate limits: sign-in, 5 attempts per 15 minutes per email and 30 attempts per 15 minutes per IP address; two-factor codes, 5 attempts per 15 minutes per user and 20 attempts per 15 minutes per IP address; sign-up, 5 attempts per hour per IP address; password reset, 3 attempts per hour per email and 10 attempts per hour per IP address. Rate-limit records hold a keyed fingerprint of the email or IP address, never the address itself.
• Every query for customer data is scoped to the signed-in user's organisation, so one customer cannot read or change another's records. Blocked attempts are written to the change log.
• Workers' private record links are random and only a hash is stored. Each expires after 180 days and stops when the worker is marked as no longer working at the venue, is removed, or the venue is archived. The Customer can revoke a link at any time, and each opening is logged at most once an hour with the IP address used.

Transport and browser security

• HTTPS only, with HTTP Strict Transport Security for two years including subdomains. Database connections use TLS or the hosting provider's private network.
• A per-request Content Security Policy that only runs scripts Fairpool served, blocks framing and limits form submissions to Fairpool and Stripe Checkout. Also: X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy and cross-origin isolation headers.
• Payment webhooks are accepted only with a valid Stripe signature from the last five minutes and a size limit. Fairpool never sees card details.
• The server refuses to start in production if security-relevant configuration is missing or invalid.

Minimisation, retention and erasure

• The change log records amounts and identifiers, not worker names. Emails never contain worker names.
• A daily job deletes an allocation and the tips in it once the end of its period, its pay-by date and its paid date are all more than 3 years ago, never while any tip in it is younger than 3 years or a correction or top-up to it is still kept. The same job deletes: tips never allocated 3 years after the day the customer paid them; corrections and top-ups 3 years after they are paid (unpaid ones are kept); hours 3 years and 2 months after the shift, unless they fall in a kept allocation; workers' requests for their records 3 years after the reply (or the request, if unanswered); replaced policy versions 3 years after replacement, unless a kept allocation began before then; archived venues and anonymised workers once none of their records is kept; former workers with no records and no change for 3 years; change-log entries after 3 years; and expired sessions, sign-in steps, links and sign-ups.
• IP addresses in change-log entries (sign-ins, blocked access attempts and private link views), and the browser details recorded with them, are removed after 12 months.
• Erasing a worker with no records deletes them. A worker with records is anonymised instead, because the Customer must keep the amounts for 3 years: their name is removed from tip notes, policy versions, consultation summaries, request notes and correction notes and references, and their private link is removed.
• Exports: each worker's data as JSON, tip records as CSV, payroll files for each allocation, and account data as JSON. Deleting an organisation permanently removes all of its data at once.

Hosting and operations

• Application and database hosted by Render Services, Inc. in Frankfurt, Germany (EU region). The provider encrypts the database and its backups at rest (AES-256) and keeps point-in-time recovery for up to 7 days.
• Planned, not yet in place: a nightly copy of the database with a second provider (Cloudflare R2, EU), in case the hosting provider is lost. It is encrypted before it leaves the hosting provider, with a key held offline by Callum Pollard, so the storage provider cannot read it; it cannot be deleted or changed early, and is deleted within 30 days. Customers get notice under section 5 before it starts.
• Production access is limited to Callum Pollard. Hosting, database, email, payment and code-hosting accounts use multi-factor authentication. Secrets are kept in environment variables, not in code.
• Changes are checked by automated tests, including accessibility checks, before release.
• Personal data breaches follow the process in section 11 and are recorded whether or not reported.