Back to CallCamIT

Data processing agreement

The Article 28 processor terms between CallCamIT and a customer.

CallCamIT — UK GDPR Article 28 terms

Version 1.5, 6 October 2026 (§0 and §3.4: a Team laptop renews its own licence once a day near its date, sending the licence it holds and its identifier; an administrator can switch it off). Forms part of the CallCamIT terms of use.

This is a draft prepared carefully, not a solicitor's work. It is written to be accurate about what the software actually does — which is the part a template gets wrong — but it has not been reviewed by a qualified lawyer, and it should be before it goes to a customer. Two of its terms are commercial choices rather than facts about the software: the notice we give of a sub-processor change (§4(d)) and the audit terms (§4(h)). Both are set to the usual ones, and either can be negotiated.

0. The unusual thing about this agreement, stated first

Most software vendors are processors because the customer's data sits on the vendor's servers. CallCamIT is not built that way. In its default configuration:

• the ticket database, the audit chain and every event transcript live on the customer's own machines;
• the AI model runs locally, so ticket content is not sent anywhere;
• there is no CallCamIT cloud service, no telemetry, and no account to sign in to;
• the licence is a signed file, verified offline. On the Enterprise plan the software never contacts us. On the Team plan a laptop contacts us when a person activates the key on it (at set-up, and after a reinstall or a lost licence file), sending the key, a laptop identifier and the laptop's hostname, and once a day near its licence's date to renew it, sending the licence it already holds and the identifier. Both reach callcamit.com from the laptop's IP address — see §3.4.

In that configuration we do not process your personal data at all beyond the Team activation record, and this agreement mostly describes what happens if that changes. It is written down rather than assumed, because "the vendor holds nothing" is exactly the claim a data protection officer will want to see supported.

The three situations where we do become a processor are named in §3: a diagnostic export you send us (§3.1), a support engagement (§3.2) and a Team key activation (§3.4). Each one only happens because somebody chose it. §3.3 explains a fourth case that is often assumed to be one and is not: a hosted AI model you configure is your processor, not ours.

1. Parties and roles

You are the controller. You decide why CallCamIT is used and what happens to the personal data in it. Your staff raise the tickets; your IT team works them; the records are yours.

We — CALLCAMIT LTD, the supplier of CallCamIT, a company registered in England and Wales with company number 17455028 and its registered office at 14 Walton Way, London W3 0AW, United Kingdom — are a processor, and only to the extent set out in §3.

Where CallCamIT reads your Microsoft 365 tenant, you remain the controller of that data and Microsoft is your processor under your own agreement with them, not ours.

2. Subject matter, duration, nature and purpose

Article 28(3) requires each of these in writing.

Types of personal data

Names, work email addresses and usernames; device identifiers and hostnames; the content of support tickets and the messages within them; technical logs about the person's machine; and records of administrative actions taken on accounts. For a Team activation (§3.4): the key, a laptop identifier, a hostname and the IP address the request came from only.

Special category data is not intended to be processed. Support tickets can nonetheless mention health, disability or union membership — somebody explaining why they need software adjusted, for example — and CallCamIT screens for that: compliance/special_category.py keeps such tickets away from a hosted provider: the local model answers them, or, where the PC has none that can, the ticket is held for a person (CC-7006). The screen covers tickets only: it does not cover a local-engine address pointed at another machine, where every ticket goes to that machine, or Admin Cam, whose instructions and the directory results it reads go unscreened to a hosted provider when one is configured and its transfer assessed (Admin Cam withholds from the model only the secrets its own tools return, such as the temporary password it generates for a new account). That is a control, not a guarantee, and §3.1 says what we do if we see such data anyway.

Categories of data subject

Your employees, contractors and agency staff. Where a ticket describes an interaction with someone outside your organisation, that person too.

3. When we process, and only then

3.1 You send us data to diagnose a fault

You export a troubleshooter report, a ticket, or a database and send it to us because something is wrong with CallCamIT.

• We use it to fix the fault and for nothing else.
• The export. We hold it for 90 days after the case closes, then delete it from our mailbox and from anywhere we saved it. Nothing does this automatically; we do it by hand when a case closes.
• If it contains special category data, we will tell you and delete it unless you instruct otherwise in writing.
• Check it before you send it. A troubleshooter report or a ticket export is not redacted when it is made. The redaction of ticket titles and resolutions applies to the estate summary CallCamIT publishes to your own share or SharePoint site, not to an export. CallCamIT does remove the credentials it recognises from a ticket's title when it stores the ticket, but that catches obvious secrets, not everything personal, so read the export before you send it.

How it reaches us, and what that means. The only route we offer is email to support@callcamit.com. The mailbox is not a closed channel, and what happens to the email depends on its subject:

• The mailbox is provided by IONOS, which is therefore our sub-processor for anything you email us (§4(d), §5). The attached export is deleted from it as above; the covering email stays until we delete it.
• To keep the email away from our email assistant, start its subject with [PRIVATE]. The assistant then leaves the email alone: it is not given to any AI model, local or hosted, so it is not sent to Groq; the assistant keeps no copy of it, drafts nothing and sends no reply; and the email stays in the mailbox for one of us to answer. [PRIVATE] must be at the very start of the subject, in any mix of capital and small letters, and may follow any number of "Re:", "Fw:" or "Fwd:" prefixes. Anywhere else in the subject it does not count, and reply prefixes in other languages ("AW:", "SV:") are not recognised. Each email is judged by its own subject, so put [PRIVATE] on every email in the thread. What remains on the assistant's server is one line in its security log saying an email was skipped, with the time and a 16-character fingerprint of the email's message ID, and no address, subject or text. If the assistant's server fails to take the email in (for example while the assistant is restarting), the software that reads the mailbox keeps that failed attempt, email included, for up to 14 days and then deletes it.
• Otherwise, our email assistant reads the email. It runs on a server we rent from IONOS and is not given files attached to the email, but it is given the text of the email itself: your address, the subject and the body. Anything you paste into the body, rather than attach, is treated the same way. So send the export as an attachment, and keep ticket content out of the covering email.
• What the assistant keeps. A copy of the subject and body (up to its first 6,000 characters) is deleted automatically 365 days after it was received. Its record of the reply it drafted or sent quotes up to the first 1,500 characters of the body, and it keeps a record of your address; neither is deleted on a schedule, and we delete them when you ask. The reply it drafts or sends, with a short summary of your email, is also emailed to us for review and stays in that mailbox until we delete it.
• Groq. To sort the email and draft a reply, the assistant sends your address, the subject and up to the first 3,000 characters of the body to Groq, an AI provider, which processes it in the United States. Groq is therefore also our sub-processor for the covering email (§4(d), §5). Groq says it does not keep this by default but may keep logs of it for up to 30 days, which we cannot delete. None of this happens to an email whose subject starts with [PRIVATE], above.
• No screening. The special-category screen in §2 is part of the CallCamIT software. Our email assistant has no such screen, so unless the subject starts with [PRIVATE] it does not stop a health or similar detail in the covering email reaching Groq.

If even the mailbox is not acceptable to you, do not send an export by email. We do not yet offer another route.

3.2 We work on your systems under a support engagement

Remote access, or hands-on-keyboard work, under a separate statement of work. That engagement's terms govern, and this agreement applies to it.

3.3 You configure a hosted AI model

This one is worth reading carefully, because it is probably not what you expect.

If you switch CallCamIT from the local model to a hosted provider, ticket text is sent from your machines directly to that provider. So are an administrator's instructions to Admin Cam and the directory results it reads; Admin Cam withholds from the model only the secrets its own tools return, such as a new account's temporary password. None of it passes through us and we never see it. That provider is therefore your processor under your own agreement with them — not our sub-processor.

CallCamIT refuses to send anything to a hosted provider until an administrator has explicitly acknowledged it (providers.chat() enforces this; the setting alone is not enough), and the troubleshooter reports an unacknowledged configuration as a failure rather than a warning. It also judges "off-site" by destination rather than by product name — an Ollama server on another machine counts as off-site, and a loopback OpenAI-compatible endpoint does not.

Before you turn that on you need a transfer risk assessment if the provider is outside the UK. compliance/transfers.py records one, and CallCamIT will not send ticket text to the provider until it exists: the local model answers where the PC has one that can, and otherwise the ticket is held for a person (CC-7006).

3.4 You activate a Team key

The Team plan sells a key rather than a licence file, and a key has to be counted. When somebody types it into a laptop and presses Activate, activation.activate_key makes one HTTPS POST to callcamit.com/api/activate.php carrying three fields: the key, a laptop identifier, and the laptop's hostname, so the key's owner can tell their laptops apart in the client portal.

• The laptop identifier is a shortened SHA-256 hash of the laptop's hardware ID: its SMBIOS UUID, or Windows' MachineGuid if that cannot be read (and, where neither can, a random ID kept with CallCamIT's data). It is not the hardware ID itself, but it is not secret either: it stays the same when CallCamIT is reinstalled on that laptop, which is how a reinstall keeps its seat, and anyone who already knows the laptop's hardware ID (an asset inventory, for example) can work it out.

• The IP address. Like any request over the internet, the activation reaches us from the laptop's IP address. Our web server keeps a shortened hash of it, with the times of recent attempts, to limit repeated activations, and deletes that record once it has not been written to for 7 days.

• The hostname can be personal data. Windows names a great many laptops after the person who set them up — JOHN-SMITH-PC is the ordinary case — and we do not strip that. It is stored against the activation and shown to two parties: us, on the licence server's administration console, and whoever signs in to the client portal (portal.callcamit.com) with the subscription's contact address.

• We hold the activation record while the key is on our books, so a reinstall is re-issued the same seat rather than charged a second one, and so the owner can deactivate a lost laptop, which frees its seat and removes the laptop from the key's list of activations.

• Every activation is also written to our ledger of issued licences, with the same laptop identifier and hostname. The licence server only ever adds to that ledger, and deactivating a laptop does not remove its entries there.

• Nothing removes any of this on a schedule: revoking a key stops its renewal and keeps its records, because they are what a later dispute about seats is settled from. Ask us and we delete them from both, removing the ledger entries by hand. We use these records for seat counting and for nothing else.

• A seat released in the client portal is also noted in the portal's event log with the laptop identifier (not the hostname). That log's lines are deleted after 12 months, and when you ask us to delete the records above we remove the identifier from it too.

• No ticket, no user, no directory data and nothing typed anywhere in the product travels with it. The licence that comes back is verified on the laptop exactly like an Enterprise one, and tests/test_clock_floor.py pins that the licence-checking module contains no network code at all.

• A laptop makes the same call, with the same three fields and the same identifier, each time a person activates the key on it again: after a reinstall or a lost licence file, or to pick up a newly paid period at once. Neither takes another seat.

• Renewal, by itself (since 6 October 2026, renewal.renew_if_due). A payment moves the date the key issues against rather than sending a new licence, so a Team laptop asks for its new period: once a day, from a week before its licence's date until a renewal is issued, it POSTs renew=1, the laptop identifier and the licence it already holds (which carries the organisation, the contact address the licence was issued to, its reference, seats and dates: what we issued it with). No key, no hostname, nothing else. We renew it only while that laptop still holds its seat, so a laptop deactivated in the client portal stops renewing. The renewal is added to the ledger of issued licences and the activation record notes when it last renewed. An administrator can switch this off with the licence_auto_renew setting, pushable by Group Policy or Intune; the laptops then contact us only when a person activates the key.

• An Enterprise licence file never makes this call. licensing.ACTIVATION_URL is the only address the product knows for us.

4. Our obligations

The eight in Article 28(3)(a)–(h), in order.

(a) We act only on your documented instructions, including about international transfers, unless required otherwise by law — in which case we will tell you first unless the law forbids it. If we think an instruction breaches UK GDPR or the DPA 2018, we will say so rather than carry it out quietly (Art. 28(3), final paragraph).

(b) Anyone we let near your data is bound to confidentiality, by contract, and only sees it if they need to for the matter in hand.

(c) We take the security measures required by Article 32. For the product itself, what those are is documented in SECURITY.md rather than summarised in marketing terms — including the residual risks we have not solved, which are listed there with the same prominence as the controls.

(d) Sub-processors. For an export and its covering email (§3.1) there are two: IONOS, which provides our support mailbox and the server our email assistant runs on, and Groq, which our email assistant sends the covering email's text to unless its subject starts with [PRIVATE]. Groq publishes its own list of the companies it uses. For the activation records in §3.4 the only one is the company hosting our licence server, IONOS, recorded in our own record of processing, and it holds those records and nothing else of yours. If that changes we will give you 30 days' notice and you may object; if you object reasonably and we cannot resolve it, you may terminate without penalty. As §3.3 explains, a hosted AI provider you configure is not our sub-processor.

(e) We assist you with data subject rights. In practice CallCamIT does most of this itself: Controller → Compliance assembles a subject access pack, services rectification, erasure and restriction, and answers Article 22 requests about automated decisions — from your own database, without us. Where a request touches something we hold under §3.1, we will provide it promptly.

(f) We assist you with Articles 32 to 36 — security, breach notification, DPIA and prior consultation. CallCamIT generates a draft DPIA and a record of processing activities from your actual configuration, and tracks the 72-hour ICO clock on any breach you log.

If we suffer a breach affecting your data, we will tell you without undue delay and in any event within 24 hours of becoming aware, with what we know at that point. We will not wait until we have the full picture, because your own 72 hours starts when you become aware.

(g) At the end we delete or return it, at your choice, and delete existing copies unless the law requires us to keep them. For the software itself there is nothing to return: it is already yours and on your machines.

(h) We will give you what you need to demonstrate compliance, and submit to audits or inspections by you or an auditor you appoint, on reasonable notice, in normal business hours, no more than once a year unless a breach or a regulator makes it necessary, and with each side bearing its own costs.

5. Transfers outside the UK

For the processing in §3.1 there are two possible transfers, and a third that is certain unless the covering email's subject starts with [PRIVATE] (§3.1):

• Our support mailbox is on an IONOS network registered in Germany. We have not confirmed where the mail server physically sits. If it is in the EEA, that is a transfer to a place UK law already treats as adequate; we will confirm the location and update this section.
• Our email assistant's server is on an IONOS network registered in the UK. That is not proof of where the machine sits either, and we have not yet confirmed it with IONOS.
• Groq processes the covering email's text in the United States and possibly other countries, so that is a restricted transfer. It does not receive an email whose subject starts with [PRIVATE]. Groq's data processing addendum, which forms part of its services agreement, applies the EU standard contractual clauses with the UK's International Data Transfer Addendum to transfers from a UK customer. We use Groq's free tier, and Groq's terms do not say in so many words that the addendum covers the free tier, so we say that plainly rather than assume it.

If any of this changes we will tell you first and put an appropriate safeguard in place, and provide it to you.

For the activation records in §3.4, our licence server is hosted by IONOS, on an IONOS network registered in Germany. We have not confirmed where the server physically sits. If it is in the EEA, that is a transfer to a place UK law already treats as adequate; we will confirm the location and update this section.

A hosted AI provider is your transfer, not ours (§3.3), and it is your assessment to make.

6. Liability

The liability provisions in the CallCamIT terms of use apply, except that nothing in them limits or excludes either party's liability under Article 82 UK GDPR to a data subject, which cannot be limited by agreement between us. That is stated here rather than left to be discovered, for the same reason the terms of use state what they cannot exclude: a limitation that fails in court is worse than one that was never claimed.

7. Priority

If this agreement and the terms of use conflict on data protection, this agreement wins. On anything else, the terms of use win.

8. Law

The law of England and Wales, and the exclusive jurisdiction of its courts.

For whoever reviews this

The claim that carries the most weight commercially is in §0 and §3: in the default configuration we hold nothing. That is not a drafting position, it is how the software is built, and every part of it is verifiable — the local model, the offline licence check, the absence of telemetry, and the enforcement point that stops ticket text reaching a hosted provider without an explicit acknowledgement. The one qualification is the Team activation call in §3.4, and it is stated rather than left for a reviewer to find in the source: tests/test_dpa.py checks that the three fields it names are the three fields the code sends. If a customer's DPO wants to test it, SECURITY.md and the troubleshooter's own report are the places to look, and both are written to be read by somebody who is checking rather than being sold to.