Data Processing Addendum

1. Scope and relationship

This Data Processing Addendum ("DPA") forms part of the Terms of Service between Cabica Ltd ("Cabica", "Processor") and the operator ("you", "Controller"). It applies whenever we process personal data on your behalf.

It is written to satisfy Article 28 of the UK GDPR and, where you are established in the EEA or processing EEA data, Article 28 of the EU GDPR.

You are the controller. You decide why and how your passengers' and drivers' data is processed. You are responsible for having a lawful basis, for your own privacy notices, and for answering the requests your people make.

We are the processor. We hold and process that data to provide the platform to you, and for nothing else.

If this DPA conflicts with the Terms of Service on a data protection point, this DPA wins.

2. What we process, and why

Subject matter

Providing the Cabica dispatch platform, driver and passenger apps, booking website, payments, telephony and reporting.

Duration

For as long as your subscription lasts, plus the 30-day export window in section 8.

Nature and purpose

Collection, recording, storage, structuring, retrieval, use, transmission, erasure. All of it in service of arranging and recording journeys.

Categories of data subject: your passengers; your drivers; your staff; people who telephone you; people named in a booking (someone a passenger is being collected for, or an account contact).

Categories of personal data:

Special category data. The platform is not designed to hold it and we do not ask for it. An operator may nonetheless record something that qualifies — an accessibility requirement noted against a passenger, for example. Where that happens you are the controller of it, you must have an Article 9 condition for it, and you should tell us so we can treat it appropriately.

Children. The platform is not intended for children. A booking may name a child passenger; where it does, you are responsible for the lawful basis.

3. Our obligations

We will:

1. process personal data only on your documented instructions — your use of the platform being the primary instruction — unless required otherwise by law, in which case we tell you first unless the law forbids it;
2. ensure everyone authorised to process the data is under a duty of confidentiality;
3. take the technical and organisational measures in section 5;
4. not engage a subprocessor without the authorisation in section 6;
5. help you respond to data subject requests, using the tools described in section 7;
6. help you with security, breach notification, impact assessments and prior consultation, taking into account what we know and what you do not;
7. delete or return the data at the end of the service, as set out in section 8;
8. make available everything needed to demonstrate compliance with Article 28, and allow and contribute to audits under section 9.

If we think an instruction is unlawful, we will tell you. We will not simply carry it out.

We will not: sell your data; use it for our own marketing; use it to train machine-learning models; share it with any other operator; or use it for any purpose other than providing the platform to you.

4. Your obligations

You will:

1. have a lawful basis for everything you put into the platform, and give your passengers, drivers and staff the privacy information they are entitled to;
2. give instructions that are lawful, and not require us to do anything that would put either of us in breach;
3. keep your own retention decisions under review, and use the platform's tools to delete what you no longer need;
4. manage your users' access properly — remove leavers, use individual logins, and enable two-factor authentication for administrative accounts;
5. answer the data subject requests your people make within the statutory deadline, and tell us if you need help;
6. tell us if you become aware of a breach that involves the platform.

5. Security measures

We implement and maintain appropriate technical and organisational measures under Article 32. Concretely:

In transit and at rest

• TLS on every connection. The mobile apps refuse plain HTTP at the platform level.
• Database and object storage encrypted at rest by the hosting provider.
• Access tokens on mobile devices wrapped in AES-256-GCM under a hardware-backed key in the device's secure element, so a stolen or imaged phone does not yield a working session.
• Passwords hashed with Argon2. One-time codes stored hashed, single-use, and expiring in ten minutes.
• Tenant secrets — payment keys, mapping keys — encrypted at rest and decrypted only in the process that needs them.

Access control

• Every request is authorised server-side against the account's role and area permissions. The interface hiding a button is not treated as a control.
• Every request re-checks that the account is still active and still belongs to the company its token claims — a token cannot outlive a suspension or a move between firms.
• Each operator's data is isolated by tenant, and every query is scoped to the caller's company.
• A boot-time check refuses to start the service if any endpoint has been left without an authorisation guard, so the failure mode is a service that will not start rather than one that quietly leaks.
• Role-based access with per-area read/write/disabled levels, so a dispatcher does not see payroll.

Monitoring and containment

• Administrative actions written to a tamper-evident audit log the operator can read.
• Rate limits keyed on the account rather than the network address, so abuse is contained without taking a whole town's drivers offline.
• Account lockout after repeated failed logins; daily ceilings on one-time codes.
• Refresh token rotation with reuse detection — a stolen token used a second time revokes the entire family.
• IP blocking, manually applied, always with a written reason.
• Uploaded documents verified against their real file signature before acceptance, with a hook for antivirus scanning.

Organisational

• Access to production data limited to those who need it.
• Two-factor authentication on administrative accounts.
• Secrets held in the hosting platform's secret store, never in the repository.
• Security review of changes, with findings documented and tracked.
• Backups on a rolling cycle of up to 35 days.

The current, detailed position — including what has been reviewed, what is deliberately accepted as a risk, and what is still open — is maintained in our security documentation and is available to operators on request at security@cabica.co.uk. We would rather show you an honest list with open items on it than a marketing page with none.

6. Subprocessors

You give general authorisation for us to engage subprocessors. Each is bound by written terms no less protective than this DPA, and we remain fully liable to you for what they do.

Current subprocessors:

Changes. We give at least 30 days' notice before adding or replacing a subprocessor, by email to your admin contact and in the platform. If you have a reasonable, data-protection-based objection, tell us within those 30 days and we will work with you to find an alternative. If we cannot, you may terminate the affected part of the service without penalty and we will refund anything paid in advance for it.

Where an operator configures their own SMS, telephony or email provider, that provider is engaged by them, not by us, and they are responsible for the terms with it.

7. Helping you answer requests

Requests from passengers and drivers come to you, because you are the controller. If one comes to us we will forward it to you promptly and will not act on it ourselves, except where you have instructed us to.

The platform includes the tools to answer them, so the answer takes minutes rather than a spreadsheet:

8. Personal data breaches

If we become aware of a personal data breach affecting your data, we will notify you without undue delay and in any event within 48 hours of becoming aware. Your own clock with the ICO is 72 hours from when *you* become aware, so ours is set to leave you a full day.

The notification will include, as far as we know it at the time:

• what happened and when;
• the categories and approximate number of data subjects and records involved;
• the likely consequences;
• what we have done and are doing about it;
• a named contact for follow-up.

We will not delay a first notification in order to make it complete. You will get what we know, then updates.

We will help you meet your own obligations to the ICO and to affected people. We will not notify your data subjects ourselves unless you ask us to, or the law requires it of us.

Report a suspected breach to us at security@cabica.co.uk at any time.

9. Return and deletion

You can export your data at any time while the subscription is live.

When it ends:

1. we keep your data available for export for 30 days;
2. after that we delete it or irreversibly anonymise it;
3. anything we must keep for our own legal obligations — invoices, payment records, the audit trail of the deletion itself — is retained under the schedule in the Privacy Policy;
4. copies in backups age out on their own cycle, up to 35 days, and are not restored except to recover from a failure.

We will certify the deletion in writing if you ask.

10. Audits and information

We will make available the information needed to show we comply with Article 28, and allow audits by you or an auditor you appoint.

• In the first instance we will answer a written questionnaire and provide our security documentation. This satisfies most requests and costs neither of us anything.
• If that is not enough, an on-site or remote audit may be carried out once in any 12-month period, on 30 days' notice, during business hours, without unreasonably disrupting the service.
• More frequent audits are available where a regulator requires one, or after a breach affecting your data.
• The auditor must be independent, not a competitor of ours, and must sign a confidentiality undertaking.
• You bear your own costs. Where an audit finds material non-compliance on our side, we bear ours.

11. International transfers

We keep data in the UK and EEA wherever we can choose. Some subprocessors process outside — the table in section 6 says which.

Where they do, the transfer relies on one of:

• an adequacy decision by the UK government or the European Commission;
• the UK International Data Transfer Addendum to the EU Standard Contractual Clauses;
• the EU Standard Contractual Clauses, with a transfer risk assessment behind them.

You authorise us to enter into those clauses with subprocessors on your behalf. Copies are available on request.

12. Liability under this DPA

Liability under this DPA is subject to the limitations in the Terms of Service, including the cap at the total fees you paid to us in the twelve months immediately before the event giving rise to the claim.

That cap does not limit either party's liability to a data subject, or to a supervisory authority, under Articles 82 to 84 of the UK GDPR. Neither of us can contract out of that, and this clause is not an attempt to.

This DPA is governed by the law of England and Wales.

Questions, audit requests and subprocessor objections: privacy@cabica.co.uk.