Status: draft. Not legal advice. Do not publish before a lawyer has read it. Of the three documents in this folder, this is the one to have reviewed most carefully — §7 (international transfers) cannot be completed from the code alone, and it is the section most likely to be wrong.

Last updated: [DATE]

Why this document exists

You collect personal data from your customers — their names, their email addresses, whatever they write in a support ticket. Under UK and EU data protection law, you are the controller of that data: you decided to collect it and you decided why. We hold and process it for you, which makes us your processor.

Article 28 of the UK/EU GDPR says that relationship has to be governed by a contract containing specific terms. This is that contract. It applies automatically when you use TicketModules; there is nothing to sign.

If your own customers are businesses in the EU, they may ask you for a DPA. This one is what lets you answer that question.

1. Definitions

Words like controller, processor, personal data, processing, data subject and personal data breach carry the meanings given in the UK GDPR and the EU GDPR (Regulation (EU) 2016/679).

Data Protection Law means the UK GDPR, the Data Protection Act 2018, the EU GDPR, and any other applicable law about processing personal data.

Customer Personal Data means personal data we process on your behalf through the service.

Sub-processor means anybody we engage to process Customer Personal Data.

2. Roles

You are the controller. We are the processor.

Where you are yourself a processor for somebody else — an agency running a desk on a client's behalf — we are a sub-processor, and you confirm you have the authority to appoint us.

A separate matter: for data about you and your staff — your account, your billing, your logins — we are a controller in our own right, and that is covered by the Privacy Policy rather than this document. The two roles are genuinely different and it is worth keeping them apart.

3. What we process, and why

Subject matter: providing the TicketModules support-desk service.

Duration: for as long as your workspace exists, plus the retention periods in §9.

Nature and purpose: storing, transmitting, indexing, backing up and displaying support conversations, so that you can answer your customers.

Categories of data subject:

• your customers and anybody who contacts your support desk
• your own staff and team members

Categories of personal data:

• name and email address
• the content of tickets, replies, live chats and attachments — which is whatever the person chose to write, and therefore not something either of us controls in advance
• the raw source of inbound emails, including headers and IP addresses
• a log of outbound emails and their delivery status
• purchase records, where you use purchase verification
• portal login credentials, where a customer sets a password

Special category data: the service is not designed for it and you should not deliberately collect it. Because ticket content is free text, a customer may nonetheless volunteer health or other sensitive information unprompted. If that is a realistic and recurring part of your support — health products, financial advice — tell us before you rely on the service, because it changes what safeguards are appropriate.

4. Our obligations

We will:

1. Process only on your instructions. Your use of the service is the instruction. We will not process Customer Personal Data for our own purposes, and we will not sell it. If the law requires us to process it otherwise, we will tell you first unless the law forbids that.
2. Keep it confidential, and ensure anybody we authorise to access it is under a duty of confidence.
3. Secure it as described in §5 and Annex B.
4. Follow §6 before engaging any new sub-processor.
5. Help you answer data subjects — see §8.
6. Help you with breach notification, impact assessments and consultations, as far as is reasonable given what we know.
7. Delete or return it when the service ends — see §9.
8. Give you the information you need to show we are meeting these obligations, and allow audits under §10.

We will tell you if we think an instruction breaks Data Protection Law.

5. Security

Taking account of the state of the art, cost, and the risk to people, we maintain appropriate technical and organisational measures — set out in Annex B, which is factual rather than aspirational and describes what the software actually does today.

6. Sub-processors

You give general authorisation for us to engage sub-processors, subject to the following.

Every sub-processor is engaged under a written contract imposing data protection obligations no less protective than these, and we remain fully liable to you for what they do.

The current list is Annex A.

Changes. We will give you at least 30 days' notice before adding or replacing a sub-processor, by email and on our website. If you have a reasonable objection on data protection grounds, tell us within those 30 days and we will work with you to find a solution. If we cannot, you may terminate and receive a pro-rata refund of the unused period — that is the remedy, and it is a real one.

Annex A is treated as part of the software. A new integration that calls somebody else's API adds a sub-processor, and a list that is not updated at the same time is an inaccurate list. It is maintained alongside the code, not reviewed annually.

7. International transfers

⚠️ This section cannot be completed from the code, and it is the one to put in front of a lawyer first.

What is factual: Anthropic and Voyage AI are United States companies, so a desk using AI features transfers Customer Personal Data outside the UK and EEA. Mailgun and Stripe both operate internationally.

What is unknown here: where you host, and what transfer mechanism each of your contracts with these providers actually relies on. Both are needed to finish this section honestly.

Where we transfer Customer Personal Data outside the UK or EEA, we will ensure an appropriate safeguard is in place — an adequacy decision, the UK International Data Transfer Agreement or Addendum, or EU Standard Contractual Clauses — and carry out a transfer risk assessment where required.

ASSUMPTION: primary hosting is in [HOSTING REGION] with [HOSTING PROVIDER]. If that is the EU or UK, your baseline position is much simpler and only the AI providers need a transfer mechanism. If it is the US, this whole section needs rewriting around that fact.

A practical point worth knowing: AI features are optional and off by default. A workspace that does not use them makes no transfer to Anthropic or Voyage AI at all, which is a straightforward way to reduce this exposure if a customer of yours objects to it.

8. Data subject requests

If somebody contacts us directly to exercise their rights over data we hold for you, we will not answer on your behalf. We will tell them to contact you, and tell you it happened.

The service gives you the tools to answer these yourself — export, and per-customer erasure. Where a request cannot be satisfied through the product, we will provide reasonable assistance.

What erasure actually does, because "delete" is used loosely and you may be asked to be precise:

• the person's name and email are replaced with an anonymous placeholder
• the text of everything they wrote is replaced with a marker
• their address and the content of emails sent to them are removed from the mail log
• the fact that an email was sent, and when, is retained — without its contents — because that is what answers a later dispute
• the erasure is recorded in the audit log

Backups. Erasure applies to the live system immediately. Encrypted backups taken beforehand still contain the data until they expire, within 14 days. We do not restore backups to recover erased data, and if a backup is ever restored after a disaster we re-apply outstanding erasures. This is true of essentially every service that takes backups; we would rather write it down than have it come up later.

9. Retention, and the end of the service

While your workspace exists, we keep Customer Personal Data as long as you keep it, subject to these automatic periods:

When you leave, you can export your data for 30 days. Deleting your workspace starts a seven-day cancellable grace period, after which deletion is irreversible: tickets, customers, attachments and archived email are destroyed. Backups age out within a further 14 days.

We will confirm deletion in writing on request.

10. Audits

On reasonable written notice, and no more than once a year unless a regulator requires otherwise or there has been a breach affecting your data, we will give you the information reasonably necessary to demonstrate compliance with this DPA.

We may satisfy this with an independent audit report or security documentation where one exists.

ASSUMPTION: no SOC 2 or ISO 27001 certification today. Enterprise customers will ask. When you have one, this clause gets easier and shorter.

11. Breach notification

We will tell you about a personal data breach affecting Customer Personal Data without undue delay after becoming aware of it, and in any event within 48 hours, with what we know: what happened, who and what is likely affected, the likely consequences, and what we are doing about it.

Notifying regulators and data subjects is your obligation as controller, because you are the one who holds the relationship with them. We will give you what you need to do it.

12. Liability

Liability under this DPA is subject to the limits in the Terms of Service, except where Data Protection Law does not permit that.

13. Conflicts

If this DPA conflicts with the Terms of Service on the processing of Customer Personal Data, this DPA wins.

Annex A — Sub-processors

Derived from the external services the application actually contacts. Several are optional and are used only if you switch the relevant feature on.

Note on webhooks: if you configure one, you choose where that data goes, and the recipient is your sub-processor rather than ours. Internal notes are never included in a webhook payload.

Annex B — Security measures

Factual as at [DATE]. Describes what the software does, not what is planned.

Access control. Passwords hashed with a modern algorithm and never stored in readable form. Optional two-factor authentication for staff. Role-based permissions, and an option to restrict an agent to only the tickets assigned to them.

Separation between workspaces. Enforced at the data-access layer rather than by each screen remembering to filter, so a new feature inherits it by default. Covered by an explicit set of isolation tests that assert one workspace cannot see another's data.

Encryption. TLS in transit. Third-party credentials encrypted at rest. Backups encrypted with AES-256 where a passphrase is configured — and the system refuses to write an unencrypted backup when one is set, rather than silently falling back.

Backups. Automated daily, stored separately from the application server, retained 14 days, and restorable — with a documented restore drill, because an untested backup is a belief rather than a safeguard.

Logging. An audit trail of significant actions with actor, timestamp and IP. Retained for the life of the workspace.

Outbound request safety. Webhook destinations are resolved and checked before every send, so the service cannot be pointed at internal infrastructure.

Abuse controls. Rate limiting on authentication, submission and outbound integrations. IP banning. Attachment type and size restrictions.

Development practice. Static analysis and an automated test suite run against every change, including tests specifically covering data isolation, access control, and the absence of unintended outbound email.