Data Processing Agreement
Draft for legal review. This agreement isn't in force yet. Bracketed text marks decisions still to make. It is meant to meet Article 28 of the UK GDPR; legal review should confirm that.
This agreement forms part of the Terms of Service between [ROCC legal entity name] ("ROCC", the processor) and the organisation using ROCC Tracker (the "organisation", the controller). Words such as personal data, processing, controller, processor, data subject and personal data breach have their meanings in the UK GDPR.
1. Roles
1.1 The organisation is the controller of the personal data it, its users, its integrations and its operatives put into Tracker or generate by using it: customers' and operatives' details, visits, messages and operatives' locations ("Customer Personal Data"). ROCC processes it on the organisation's behalf.
1.2 ROCC is a controller, not a processor, for the data it needs to run its own business: account users' sign-in details, billing contacts and payments, and security records. The privacy notice covers those.
1.3 Annex 1 describes the processing.
2. ROCC's obligations
ROCC will:
- process Customer Personal Data only on the organisation's documented instructions, unless the law requires otherwise (and then tell the organisation first, unless the law forbids it). The organisation's instructions are these terms and its use and configuration of Tracker. ROCC will tell the organisation if it thinks an instruction breaks data protection law;
- make sure everyone at ROCC who can access Customer Personal Data is bound by confidentiality;
- take the technical and organisational measures in Annex 2;
- use subprocessors only as set out in section 3;
- help the organisation, taking into account the nature of the processing, to respond to data subjects exercising their rights. Tracker's admin and API let the organisation find, export, correct and delete the data itself; ROCC will pass on any request it receives directly, without responding to it;
- help the organisation with security, breach notification, data protection impact assessments and prior consultation, taking into account the nature of the processing and the information available to ROCC;
- notify the organisation without undue delay, and in any case within [48 hours], after becoming aware of a personal data breach affecting Customer Personal Data, with the information the organisation needs to meet its own obligations;
- at the end of the service, delete Customer Personal Data as set out in section 5, unless the law requires ROCC to keep it;
- make available the information needed to show it meets this agreement, and allow and contribute to audits, as set out in section 6.
3. Subprocessors
3.1 The organisation gives general authorisation for ROCC to use subprocessors. The current list is on the subprocessors page.
3.2 ROCC will give at least [30 days'] notice of a new subprocessor by updating that page and emailing account owners. The organisation may object on reasonable data protection grounds within that period. If the two can't resolve the objection, the organisation may end the affected service and get a refund of fees paid for the period after it ends.
3.3 ROCC will put a written contract with each subprocessor giving the same protections as this agreement. ROCC stays responsible to the organisation for its subprocessors.
4. Location and transfers
4.1 In production, ROCC stores Customer Personal Data in Cloudflare's EU jurisdiction: visit records, the live state and location trail of each journey, and operative photos.
4.2 Requests pass through Cloudflare's global network on their way to that storage, and some subprocessors are outside the UK. Where personal data is transferred outside the UK, ROCC will make sure there's a lawful transfer mechanism, such as UK adequacy regulations, the UK International Data Transfer Agreement or Addendum, or the UK Extension to the EU–US Data Privacy Framework.
5. Retention and deletion
5.1 While the organisation's account is open, Tracker keeps data for the periods the organisation chooses in its settings, within these limits, and deletes it automatically afterwards:
| Data | Kept |
|---|---|
| A journey's location trail | Set by the organisation, up to the plan's maximum (24 hours, or 30 days with visit history); then deleted automatically |
| Visit records (customer, address, times, actual journey time and distance) | Set by the organisation, 6 to 36 months after the visit (24 by default); then deleted automatically |
| Customer message log | Set by the organisation, 3 to 24 months (12 by default); then deleted automatically |
| Operatives' details and photos | Until the organisation removes them. Photos can be removed at any time. |
| Operatives' paired-device records | Until signed out, then [90 days] |
5.2 After the account closes and the export period in the Terms of Service ends, ROCC deletes Customer Personal Data within [30 days]. Backups are overwritten within a further [30 days].
6. Audits
6.1 ROCC will answer reasonable written questions about its compliance, and share summaries of relevant security assessments, at no charge [once a year].
6.2 If those aren't enough to show compliance, or a regulator requires it, the organisation may audit ROCC with at least [30 days'] notice, during business hours, under confidentiality, and at its own cost.
7. The organisation's obligations
The organisation will:
- have a lawful basis for the processing, and give people the information the law requires, including through the visit tracking notice and operative notice templates or its own notices;
- carry out a data protection impact assessment where it's required (see the guidance);
- not instruct ROCC to process data unlawfully;
- not put special category or criminal offence data into Tracker unless agreed in writing.
8. Liability
Each party's liability under this agreement is subject to the limits in the Terms of Service. [Whether data protection claims have a separate cap is to be decided.]
Annex 1: Description of the processing
| Subject matter and duration | Providing Tracker for the length of the Terms of Service, plus the deletion period in section 5 |
| Nature and purpose | Telling the organisation's customers when an operative is on the way; planning and assigning visits; sharing operatives' locations while they travel to a visit; showing operatives' photos to customers while on the way; sending visit messages; visit history and reporting; matching completed journeys to the road map, and deriving anonymous journey timings (area, hour of the week, distance, times) to improve arrival estimates [legal review: controller for the anonymisation step?] |
| Data subjects | The organisation's customers or residents, and people at the visit address; the organisation's operatives, employees and contractors |
| Customer data | Name, email address, phone number, visit address and UPRN, visit reference, appointment window, visit status and times, messages sent; if the customer turns on notifications, their browser's push subscription (an address at the browser maker's notification service) until the visit ends |
| Operative data | Name, email address, phone number, photo (if added), paired devices (device name, first and last seen), location while travelling to a visit (coordinates, accuracy, heading, speed, time), actual journey time and distance |
| Special category data | None intended (see section 7) |
Annex 2: Technical and organisational measures
- In transit: encrypted with TLS. The admin's session cookie is HTTP-only, secure and same-site.
- At rest: encrypted by the hosting provider.
- Separation: each organisation's data is separated in every query. Tracking and share-location links are long and random, work only for their own visit, and stop showing a location when the visit ends.
- Passwords, keys and tokens: passwords are hashed with a slow salted hash. API keys, device tokens and sign-in codes are stored only as hashes. Repeated failed sign-ins lock the account temporarily.
- Minimising data: location is collected only between setting off and arrival. Trails are deleted automatically after the retention period. Customers see only the operative's name, photo and position for their own visit. Photos added in the admin are resized and stripped of embedded details (such as where they were taken) before upload.
- Access: only named ROCC staff can use the platform console, signing in with their ROCC Microsoft account. They access an organisation's data only to support or secure the service.
- Resilience: managed hosting with point-in-time database recovery. [Recovery objectives to be decided.]
- People: confidentiality obligations and data protection training for staff with access.
- Testing: automated tests for separation between organisations and for security controls. [Independent penetration testing before launch.]