Business contract template · English

Data Processing Addendum (DPA)

Pre-launch template only. It is designed to cover the core controller/processor terms expected by GDPR Article 28, but it is not effective until incorporated into a customer agreement and completed/reviewed by qualified counsel.

Version/effective date: REQUIRED OPERATOR INPUT

1. Parties and roles

Customer/Controller: REQUIRED CUSTOMER/OPERATOR INPUT
YardMate Operator/Processor: REQUIRED OPERATOR INPUT: legal name, registration, address and contact.

This DPA applies where the Customer determines the purposes and means of processing personal data placed in YardMate and the Operator processes that data on the Customer's documented instructions. It does not change any processing for which the Operator independently determines purposes and means as controller; that processing is described in the Privacy Notice.

2. Processing details

Subject matter: provision, security, support and administration of YardMate stable/horse-management services.
Duration: the customer agreement plus the documented return/deletion and backup-expiry period.
Nature/purpose: hosting and displaying authorised stable records; staff/role management; task coordination; ride logging; optional user-triggered route storage; support, security and recovery.

Data subjects may include: stable owners/managers, Stable Hands, horse owners, riders, contractors and authorised support contacts. Minors must not be included unless the Customer has completed the applicable legal/safeguarding analysis.
Personal data may include: names, roles, membership status, rider associations, task/audit events, notes, support data, photos containing people, device/security data and optional precise ride location. Human special-category/sensitive data is not an intended YardMate data type.

3. Documented instructions

The Processor will process Customer Personal Data only on documented instructions from the Controller, including the Customer's configured use of YardMate and written support instructions, unless applicable law requires otherwise. If legally permitted, the Processor will inform the Controller before processing required by law. The Processor will promptly inform the Controller if, in its reasonable view, an instruction infringes applicable data-protection law.

4. Confidentiality and authorised personnel

The Processor will limit access to personnel who need it for authorised service duties and will ensure those persons are bound by appropriate confidentiality obligations. Production access procedures, privileged-access review and staff confidentiality terms: REQUIRED OPERATOR INPUT / OPERATIONAL EVIDENCE.

5. Security

The Processor will implement technical and organisational measures appropriate to the risk. The current application design includes stable/role isolation, hashed PIN verification, HttpOnly/SameSite sessions, CSRF protection, private media delivery, separation of exact route points, restricted route access, audit history, no broad API caching and production configuration gates. Production controls must additionally include HTTPS, strong secret management, restricted administrator access, monitoring, vulnerability/dependency management, backups with restore tests, incident response and appropriate infrastructure/database controls.

The Processor does not promise that the service is risk-free. The final production security schedule and any customer-specific security requirements: REQUIRED OPERATOR INPUT.

6. Subprocessors

The Controller gives REQUIRED OPERATOR INPUT: choose specific or general written authorisation model for subprocessors. The Processor will maintain a current subprocessor list identifying the provider, service, processing location and function, and will impose materially equivalent data-protection obligations on each subprocessor. Under a general-authorisation model, the Processor will give reasonable advance notice of additions/replacements and a meaningful opportunity to object on data-protection grounds.

Initial production subprocessor list and notice channel: REQUIRED OPERATOR INPUT.

7. International transfers

The Processor will not transfer GDPR-protected Customer Personal Data outside the EEA or otherwise make a restricted transfer except on documented instructions and using a lawful transfer mechanism. Where needed, the parties will use the applicable European Commission Standard Contractual Clauses and complete any required transfer-impact/supplementary-measures assessment. UK transfer terms and Qatar PDPPL requirements must be addressed separately where applicable. Hosting/data-region and transfer schedule: REQUIRED OPERATOR INPUT.

8. Individual rights

Taking into account the nature of processing, the Processor will reasonably assist the Controller with requests for access, rectification, erasure, restriction, objection, portability and other applicable rights. If the Processor receives a request relating to Customer-controlled data, it will not independently decide the merits unless legally required; it will notify or direct the request to the Controller where appropriate. The Controller remains responsible for responding within applicable deadlines.

9. Personal-data breaches

The Processor will notify the Controller without undue delay after becoming aware of a personal-data breach affecting Customer Personal Data and will provide available information reasonably needed for the Controller's assessment/notification duties. The Controller remains responsible for any regulator/data-subject notice it must make, including GDPR's controller 72-hour authority-notification rule where applicable. Incident contact, escalation path and target processor notification window: REQUIRED OPERATOR INPUT.

10. DPIAs and regulator cooperation

The Processor will provide reasonable information/assistance for data-protection impact assessments and prior consultation where the Customer's use creates a legal requirement, taking account of the information available to the Processor. Systematic staff location monitoring, large-scale sensitive-data use, children's data or materially different automated decision-making must be separately assessed before activation.

11. Return, deletion and retention

At termination and at the Controller's choice, the Processor will return or delete Customer Personal Data that the Processor is not legally required to retain, subject to the agreed export window, backup cycle and documented technical limitations. Where records must be retained, processing will be restricted to the retention purpose. YardMate's account-removal workflow may de-identify personal profiles while preserving stable-owned/audit records with a documented reason. Exact production retention/export/backup periods: REQUIRED OPERATOR INPUT.

12. Demonstrating compliance and audits

The Processor will make available information reasonably necessary to demonstrate compliance with its processor obligations and will allow/contribute to proportionate audits or inspections as required by applicable law and the customer agreement, subject to reasonable confidentiality, security, scope, scheduling and cost protections. Audit process and security-report availability: REQUIRED OPERATOR INPUT.

13. Customer obligations

The Controller is responsible for lawful instructions, transparency notices, legal bases, role/member administration, data minimisation, accuracy, responding to rights requests, and ensuring it is permitted to enter information about staff/riders/other people. The Customer must not use YardMate for covert employee monitoring or instruct the Processor to store human sensitive/special-category or children's data without completing the required legal analysis and safeguards.

14. No sale, behavioural ads or general AI training

Under the current service design, the Processor will not sell Customer Personal Data, use it for cross-context behavioural advertising, or use it to train a general-purpose AI model. A future feature requiring materially different processing must be separately documented and, where required, separately agreed before that processing begins.

15. Precedence and signatures

If this DPA conflicts with the customer agreement on protection of Customer Personal Data, the DPA should prevail to the extent required by applicable data-protection law. Governing law, SCC module/annex choices, commercial audit terms, signature method and order-of-precedence language: REQUIRED OPERATOR INPUT AND LEGAL REVIEW.

Schedule A — processing inventory

• Account/member names, IDs, roles and statuses.
• Stable work assignments and task/audit events identifying staff.
• Ride records identifying riders; optional precise route points when deliberately saved.
• Customer-entered notes/files/photos that may contain personal data.
• Authentication/security/support metadata needed to operate and protect the service.

Retention, frequency/volume, data regions, subprocessors and controller-specific instructions: REQUIRED OPERATOR INPUT.

Schedule B — technical and organisational measures

• Role and stable-scoped authorisation; least-privilege design.
• PINs stored as salted password-style hashes with keyed lookup, never readable PINs.
• HttpOnly/SameSite session cookie, CSRF protection and explicit production CORS/HTTPS gates.
• Private horse-media delivery and no-store/non-indexing controls for private data.
• Exact route coordinates separated from general ride metadata and restricted to authorised access.
• Audited task/account-removal history and server-side boundary enforcement.
• Production infrastructure controls, monitoring, backups/restore, vulnerability management and incident response remain operator deployment obligations.