Data processing agreement

1. Who this agreement is between, and when it applies

This Data Processing Agreement (“DPA”) is between Mettux Ltd, a company registered in England and Wales (company number 17497743), registered office Suite RA01, 195-197 Wood Street, London E17 3NU, trading as StableSync (“we”, “us”, the “Processor”), and the organisation or person that has opened a yard account on StableSync (“you”, the “Yard”, the “Controller”).

It forms part of our Terms of Service and applies whenever we process personal data on your behalf as your processor: the data you and your staff, clients and providers put into StableSync about people and horses. It is written to meet Article 28(3) of the UK General Data Protection Regulation (“UK GDPR”) and the Data Protection Act 2018. If your yard is in the European Economic Area, the same terms apply under the EU GDPR.

It does not cover the data for which we are the controller ourselves — your account registration, sign-in, billing with us, and our own support emails. That processing is described in our Privacy Policy.

By opening or keeping a yard account you accept this DPA. If you need a signed copy for your records, email [email protected] and we will provide one.

2. Definitions

• “Data protection law” means the UK GDPR, the Data Protection Act 2018 and, where it applies to you, the EU GDPR (Regulation (EU) 2016/679).
• “Personal data”, “controller”, “processor”, “data subject”, “processing” and “personal data breach” have the meanings given in data protection law.
• “Yard Data” means the personal data you process through StableSync as controller, described in Annex 1.
• “Sub-processor” means another processor we engage to help provide the service, listed in Annex 3.
• “Service” means the StableSync platform and its features as described in the Terms of Service.

3. Details of the processing

The subject matter, duration, nature and purpose of the processing, the types of personal data and the categories of data subjects are set out in Annex 1. In short: we store and process the records your yard keeps in StableSync, for as long as your yard account exists plus the deletion period in section 12, so that you can run your yard.

4. Our obligations: acting on your instructions

We will:

• process Yard Data only on your documented instructions, including any transfer outside the United Kingdom, unless the law requires us to do otherwise — in which case we will tell you first, unless that law prevents us on important grounds of public interest;
• treat these as your instructions: this DPA, the Terms of Service, your use and configuration of the Service (for example turning a feature on or off in Settings), and any further written instruction you give us that is consistent with the Service;
• tell you straight away if, in our opinion, an instruction would break data protection law, and we may pause that instruction until it is resolved;
• not use Yard Data for our own purposes, sell it, or use it to train or improve any software model;
• keep the records of processing that Article 30 UK GDPR requires of a processor, and make them available to you on request.

5. Confidentiality

Only people we authorise can access Yard Data, and only when needed to run, support or secure the Service. Each of them is bound by a duty of confidentiality, either in their contract with us or by law. Access to the production databases is limited to our directors, uses individual credentials and the platform admin console, which requires an authenticator code. The keys that decrypt backups are held by two named directors only.

6. Security measures

We will put in place and keep up the technical and organisational measures described in Annex 2, so that the processing is as secure as the risk requires under Article 32 UK GDPR. They include encryption in transit, a separate database for every yard, role-based access controls, two-factor sign-in, audit logging, encrypted nightly backups and a tested restore procedure. We may improve these measures over time; we will not reduce the overall level of protection during the term of this DPA.

7. Sub-processors

You give us general written authorisation to engage the sub-processors listed on our Sub-processors page (Annex 3). For each sub-processor we:

• engage it under a written contract that imposes data protection obligations at least as protective as those in this DPA, in particular on security and confidentiality;
• check its data protection commitments and the location of its processing before using it;
• remain fully responsible to you for its performance of those obligations.

Notice of changes. We will give you at least 30 days' notice before adding or replacing a sub-processor, by updating the Sub-processors page and emailing the yard owner. You may object within that period on reasonable, data-protection grounds. If we cannot resolve your objection — for example by offering a way to use the Service without the new sub-processor — you may end your subscription for the affected feature, or for the Service, before the change takes effect, with a pro-rata refund of any pre-paid fees for the period after termination.

Some sub-processors are used only when a person or your yard chooses a feature (sign-in with Google or Facebook, push notifications, translation, reading photos, smart search, answers from your records). Your yard owner can switch translation, reading photos, smart search and answers from your records off for the whole yard in Settings → Outside services; nothing is sent to those providers while a switch is off. Answers from your records is off until the owner switches it on, because it sends records and not only a question. Reading photos, smart search and answers from your records also send nothing until we have enabled the feature for your yard on our side (Annex 2).

8. International transfers

Yard Data is stored in the United Kingdom (application hosting in London, databases in London). Some sub-processors process limited data in the European Union or the United States, as shown on the Sub-processors page: sign-in providers (Google, Meta), push notification delivery, payment processing (Stripe), error reporting (Sentry's EU region), transactional email (Resend's EU region), encrypted backup storage (GitHub), translation (DeepL, EU), and reading photos, smart search and answers from your records (Anthropic, United States).

We will not transfer Yard Data outside the United Kingdom except to a sub-processor on that page, and only where the transfer is covered by one of these: the country has been found adequate by the UK (this includes the EU and EEA); the UK Addendum to the EU Standard Contractual Clauses or the UK International Data Transfer Agreement is in place with the recipient; or the recipient is certified under the UK Extension to the EU–US Data Privacy Framework. Transfers to sub-processors in the United States are made under the UK Extension to the EU–U.S. Data Privacy Framework where the provider is certified, and otherwise under the UK International Data Transfer Addendum in that provider's data processing terms.

9. Helping you with people's rights

People whose data you hold may ask you to see it, correct it, delete it, restrict it, move it or object to it. The Service lets you handle most of these yourself:

• Access and portability: Admin → Users → “Download their data” produces a copy of everything the yard holds about a person; Settings → Export produces the whole yard's data as CSV files.
• Correction: every record can be edited by a user with the right permission.
• Deletion: a person can request deletion from their profile, or a yard admin can raise it for them; it is carried out once approved and at least 30 days after the request, as described in section 12.

If a person contacts us directly about data your yard holds, we will not answer on your behalf; we will pass the request to you without undue delay and tell the person we have done so. Where you cannot deal with a request using the Service, we will help you within 10 working days of your asking, taking into account the nature of the processing and the information available to us.

10. Helping you with security, impact assessments and the ICO

Taking into account the nature of the processing and the information available to us, we will help you meet your own obligations on security (Article 32), breach notification (Articles 33 and 34), data protection impact assessments (Article 35) and prior consultation with the Information Commissioner's Office or another supervisory authority (Article 36). This DPA, Annex 2 and the Sub-processors page are designed to give you most of what an impact assessment needs; we will answer reasonable written questions beyond that. We may charge a reasonable fee for help that goes well beyond what the Service and this DPA already provide, and will tell you before any cost is incurred.

11. Personal data breaches

If we become aware of a personal data breach affecting Yard Data, we will notify the yard owner by email without undue delay and in any case within 48 hours of becoming aware of it. The notice will describe, so far as we know at the time: what happened, the categories and approximate number of people and records concerned, the likely consequences, what we have done or propose to do about it, and a contact for more information. We may give the information in stages as we learn more. We will keep a record of every breach, help you with any notification you must make, and not tell a supervisory authority or the affected people on your behalf unless the law requires it or you ask us to.

12. Return and deletion at the end

You can export your yard's data at any time while your account is open (Settings → Export). When your subscription ends, or you ask us to delete your yard, the following happens:

• A deletion request is created. It is carried out once approved by the yard owner (or by us, where you have asked us to close the yard) and at least 30 days after the request: a cooling-off period, counted from the request, during which it can be withdrawn and the data can still be exported.
• After the cooling-off period, an automatic daily process deletes the yard: billing is cancelled, uploaded files are deleted, the yard's database is dropped, and the yard's registry record is removed. Each step is verified before the next; the yard owner receives an email when it is complete.
• Encrypted backup copies expire within 35 days of the deletion. Should a backup ever be restored, every deletion completed after that backup was taken is applied again, so deleted data does not come back.
• We keep only what the law or a legitimate interest requires after deletion, in the minimum form, for the periods in our retention schedule: invoices and payment records (six years, with the person's details removed), consent and audit entries (six years, name replaced by “Erased user”), the record that the deletion itself was requested, approved and completed (six years, no name or email), and staff hours, pay and holiday records (six years, without name or notes).

An individual person at your yard can be deleted in the same way without closing the yard: the same cooling-off applies, their records are removed or anonymised according to the retention schedule, and messages they sent stay visible to the other participants without their name.

13. Information and audits

We will make available to you the information needed to show that we meet our obligations under Article 28 UK GDPR. In practice this means: this DPA and its annexes; the Sub-processors page; written answers to a reasonable security questionnaire, at most once a year; and summaries of our backup and restore drills on request.

If that is not enough for you to meet a legal obligation, you (or an independent auditor you appoint, bound by confidentiality) may audit our processing of Yard Data once in any 12-month period, on at least 30 days' written notice, during normal business hours and without disrupting the Service. You bear your own costs and our reasonable costs of taking part. The 30-day notice and once-a-year limit do not apply if the audit is required by a supervisory authority or follows a personal data breach affecting your yard. An audit may not access another yard's data or our sub-processors' premises; for sub-processors we will provide their own audit reports or certifications where available.

14. Your obligations as controller

As controller, you are responsible for:

• having a lawful basis for the data you put into StableSync and telling the people concerned how you use it (for example in your livery contract or a privacy notice);
• the accuracy of the data, who at your yard can see it, and the permissions you give each user;
• obtaining a parent's or guardian's agreement before recording a child under 16 as a client or contact;
• keeping your own sign-in credentials safe and turning on two-factor sign-in for users who handle sensitive records;
• deciding whether to use the optional features that involve a sub-processor (section 7), and switching them off if your circumstances require it;
• responding to data subject requests and notifying the ICO or people affected by a breach where the law requires you to.

15. Liability

Each party is liable to the other for breach of this DPA in accordance with the Terms of Service, including the limitation of liability in the Terms. Nothing in this DPA limits either party's liability to a data subject or to a supervisory authority under data protection law, which is set by that law. Where both parties are responsible for the same damage, each is liable for its share.

16. Term, changes and governing law

• Term: this DPA applies from the day your yard account is opened until all Yard Data has been deleted or returned under section 12.
• Changes: we may update this DPA to reflect changes in the law, in the Service or in our sub-processors. Changes that reduce your protection take effect 30 days after we email the yard owner; other changes take effect when published. The “Last updated” date shows the current version.
• Precedence: if this DPA conflicts with the Terms of Service on a matter of data protection, this DPA prevails.
• Governing law: this DPA is governed by the laws of England and Wales, and the courts of England have exclusive jurisdiction, as set out in the Terms of Service. Nothing in this clause removes any right a data subject has under data protection law.
• Contact: questions about this DPA: [email protected], or write to Mettux Ltd, Suite RA01, 195-197 Wood Street, London E17 3NU.

Annex 1 — Description of the processing

Annex 2 — Technical and organisational measures

These are the measures in place on the date at the top of this page. They describe what the Service does, not an aspiration.

Encryption and transport

• All traffic between browsers, the application and the databases uses encrypted connections (HTTPS/TLS); plain HTTP is redirected.
• Passwords are stored only as salted bcrypt hashes. Authenticator (two-factor) secrets are encrypted at rest with a key held outside the database.
• Nightly backups are encrypted with age public-key encryption before they leave the backup machine; the private keys are held by two directors in password managers and are never stored with the backups or in the application.
• Uploaded files are stored in a private bucket, encrypted at rest by the storage provider, and served only through the application after a sign-in and permission check.

Separation and access control

• Every yard has its own database. Users at one yard cannot reach another yard's data, and every request is scoped to the yard it was made on.
• Role-based permissions (owner, manager, staff, client and custom roles) control what each user can see and do; write and delete actions require the matching permission, not just read access.
• Two-factor sign-in with an authenticator app and recovery codes is available to every user. The platform administration console requires an authenticator code and a separate administrator credential.
• Sessions expire after seven days; session tokens are signed and encrypted and cannot be read by other websites.
• Provider links (vet, farrier) give access only to the horses the yard selects, for a period the yard sets, and can be revoked at any time.
• Professionals with their own account (vets, farriers and others) see only the horses the yard lists on their provider card, through pages written for them, and nothing else in the yard (no billing, staff, messages or settings). Access is checked on every request, so removing a horse or the link takes effect at once.
• Private calendar links (to show a person's shifts, bookings and care dates in their phone's calendar) are stored only as a one-way hash, can be replaced or turned off by the person, and return only what that person may see, checked on every fetch. The calendar app the person subscribes with keeps its own copy: that is the person's choice, not our sub-processor.
• Requests are rate-limited; outgoing requests to addresses supplied by users are checked against an allow-list of protocols and resolved before they are fetched, to prevent the Service being used to reach internal systems.
• Service credentials are issued with the minimum permissions each provider allows (documented key scopes for Stripe, storage and the database).

Data sent outside the platform

• Every call to an outside service (translation, reading photos, smart search, answers from your records) checks the yard's switch immediately before sending; if the switch is off or cannot be read, nothing is sent.
• Reading photos, smart search and answers from your records also need a provider key and the yard to be on our list of yards these features are enabled for; smart search and answers from your records need a platform-wide setting as well. A yard not on that list sends nothing even with its own switch on. Each has a daily limit per yard and across the platform.
• Answers from your records send only records the person asking may see, applying their horse access, permissions and the yard's modules on every lookup. Emergency contacts' phone numbers and email addresses are not sent; medicine details only where the person may see medicines. The provider's answer can only propose a record, which the person checks and saves through the normal form; the provider never writes to the yard's database.
• Weather lookups send the yard's map coordinates only.
• Error reports contain technical details of the fault, not form contents, cookies or passwords; no performance traces or session replays are collected, and nothing is reported from the browser.

Accountability and monitoring

• An activity log records significant actions in each yard, with who did them. Each subject-access export is itself logged.
• Consent decisions are recorded with their version, time, IP address and device.
• Scheduled jobs (reminders, invoicing, backups, deletions, retention clean-ups) report their result to an administration console; a daily watch job emails the administrators if any job is missing, late or failed.
• A weekly check compares file records in each database with the files in storage and reports any mismatch.

Backup, recovery and deletion

• Every night a consistent copy of each database is taken, verified as restorable, encrypted and stored; sets are kept for 35 days.
• A restore drill is run at least monthly and after any change to the backup process; it checks file integrity, restores into a clean database, compares every table's row count with the manifest and confirms the schema matches. Evidence of each drill is kept.
• Deletion of a person or a yard runs through verified stages after a 30-day cooling-off period, and a restore re-applies every deletion completed since the backup was taken.
• A written retention schedule defines what is kept after deletion, why, for how long, and how it is removed; expired records are removed by a daily job.

Organisational

• Production access is limited to the directors, with production credentials kept separately from development and loaded only for specific operations.
• Changes to the software pass automated tests and type checks before release, and changes to authentication, permissions, billing or the database schema receive an independent review against written rules for authentication, permissions, tenant scoping and input validation.
• Sub-processors are reviewed before use and listed publicly, with notice of changes (section 7).

Annex 3 — Approved sub-processors

The current list, with each sub-processor's purpose, the data involved and its location, is maintained on our Sub-processors page, which forms part of this DPA. On the date at the top of this page it comprises: Vercel (hosting), Neon (databases), Cloudflare (file storage), Resend (email), Stripe (payments), Sentry (error reporting), GitHub (encrypted backups), ImprovMX (inbound email forwarding); and, for optional features only: Google and Meta (sign-in), browser push services (notifications), DeepL (translation), Open-Meteo (weather, no personal data) and Anthropic (reading photos, smart search, answers from your records).