Data processing addendum

This applies where you are a controller of personal data and we process it for you — which for a business using Dispatch on behalf of its clients is the normal case. It forms part of the terms between XONIK Technologies Private Limited and you, and takes precedence over them on anything about personal data.

Roles

You are the controller. We are the processor. Where you are yourself a processor for your own client, we are the sub-processor and this addendum flows down: the same obligations apply to us that apply to you.

Scope

Your instructions

The panel and these terms are your documented instructions. We process only on them, and we will tell you if we believe an instruction breaks data protection law rather than carrying it out quietly.

Our obligations

• Process only on your documented instructions.
• Bind everyone with access to confidentiality.
• Keep the measures below, and not weaken them during the term.
• Help you answer a person's rights request. Export and erase are already self-service, so most of this needs nothing from us.
• Help you with impact assessments and with consulting a regulator, given the information we hold.
• Tell you without undue delay of any personal data breach, and in any event within 72 hours of becoming aware, with what we know at the time. We will tell you as soon as we can rather than waiting for the deadline — you have your own 72 hours to a regulator, and it starts when you learn of it.
• Delete or return everything on termination — erase is a button, and it genuinely deletes, including the files on disk. It reports honestly what it could not clear rather than a cheerful zero.
• Allow an audit no more than once a year on 30 days' notice, at your cost, or provide a report in its place.

Measures actually in place

Written as what the software does, not as what a certificate says. The current list, and everything not held, is on the security page.

• LinkedIn tokens encrypted at rest and authenticated on read; a tampered record fails rather than decrypting to nonsense.
• Passwords hashed with scrypt, salted per user.
• Every account isolated by an account tree enforced in one place, and tested by enumerating every route the application exposes and attacking each one with an identity that must not reach it — so a route added later without a check fails without anyone remembering to test it.
• Refusals never confirm whether an account exists.
• Sign-in throttled on both the address and the network address.
• An audit log that nothing in the system updates and only erasure deletes. Erasing an account removes its audit rows with everything else, leaving one row that records the erasure happened.
• Encrypted transport, and a session cookie that is HttpOnly and SameSite.
• Deletion on a schedule, per table, with a written reason for each — and a check that fails if a table exists with no rule.
• Nightly backup of the database and the graphics together, kept 30 days.

Sub-processors: ours, and yours

Ours are three. Hosting, mail, and the network itself for the publishing. Each is named, with its region, on the security page, which is generated from the running system rather than maintained separately. We will give 30 days' notice before adding one, and you may object on reasonable data protection grounds; if we cannot resolve it, you may end the account and we will refund the unused part of the period.

Two more are yours, not ours, and the architecture is why. The model provider whose key you entered, and the developer application you connect to the network with if you use your own rather than ours. In both cases the account is yours, the credential is yours, the contract with that vendor is yours and the bill reaches you from them. We do not resell model access and do not mark it up; the calls do not leave under our key, so we could not. They are named on the security page as yours so that an auditor can see them, and they are listed there rather than here because which ones they are is a fact about your account rather than about this addendum.

Where it runs

The hosting provider and its region are named on the security page from this deployment's own settings. Where that has not been filled in, that page says so plainly rather than printing a plausible region: an unanswered question is more useful to a buyer than a confident wrong answer.

The company is Indian and operates from India, so staff access to systems is from India, and the governing law is the one named at the foot of the terms. Transfers out of your own region are covered immediately below.

Transfers

Where personal data leaves the region named on the security page, the transfer relies on the standard contractual clauses or on an adequacy decision, whichever applies to that provider. The clauses themselves, Module Two, with the UK Addendum and the Swiss adaptations, are in the annex to this addendum below.

Liability

The limits in the terms apply to this addendum as well, except where the law does not permit them.

Ending

This addendum lasts as long as we process personal data for you. On termination you may export everything, for as long as the account exists. We do not delete on a timer — erase is yours to press, and it is immediate. You can erase it yourself at any time and it happens immediately.

Annex: international transfers

This annex applies where you are established in the European Economic Area, the United Kingdom or Switzerland, or where the personal data you send us is otherwise protected by the EU or UK GDPR. It is part of the addendum and needs no separate signature: accepting the addendum accepts this.

Why it is needed

The application and its database run at Contabo GmbH in Germany (European Union). XONIK Technologies Private Limited is established in India, which the European Commission has not made an adequacy decision about. Our people access the service from India in order to run and support it. That access is itself a restricted transfer under Chapter V of the GDPR, whichever country the server sits in, and it is the transfer this annex covers.

The clauses

The Standard Contractual Clauses adopted by the European Commission in Implementing Decision (EU) 2021/914 are incorporated into the addendum by reference, in full, and are available in the Official Journal at eur-lex.europa.eu. Where anything in the addendum or the terms conflicts with them, the clauses win.

The optional and modular parts are settled as follows, so that nobody has to negotiate them:

The governing law of these clauses is not the governing law of the terms. The terms are under Indian law because that is where the company is; the clauses must be under the law of an EU member state because the Commission requires it, and one is chosen so that a European customer is not asked to enforce a European instrument somewhere it cannot be enforced.

The United Kingdom

For personal data protected by the UK GDPR, the Information Commissioner's International Data Transfer Addendum (version B1.0) is incorporated on the same terms, taking the clauses above as its Approved EU SCCs. Table 1 is the parties in Annex I.A below; Tables 2 and 3 are the annexes below; in Table 4, neither party may end the addendum when the Approved Addendum changes. The Addendum is published by the ICO at ico.org.uk.

Switzerland

For personal data protected by the Swiss FADP, the clauses apply with the Federal Data Protection and Information Commissioner as the supervisory authority, references to the GDPR read as references to the FADP, and the term “member state” read so that a data subject in Switzerland may enforce the clauses where they live.

Annex I.A — the parties

Annex I.B — description of the transfer

This is the same record of processing published on the security page, so the two cannot drift apart.

Annex I.C — competent supervisory authority

The supervisory authority of the member state in which you are established. Where you are not established in the Union, the supervisory authority of the member state in which your Article 27 representative is established, or in which the data subjects whose data is transferred are located. For the United Kingdom, the Information Commissioner's Office. For Switzerland, the Federal Data Protection and Information Commissioner.

Annex II — technical and organisational measures

These are the measures actually in force, listed on the security page and generated from the same source, which is why this annex cannot describe a system we are no longer running.

• LinkedIn tokens encrypted at rest. Sealed before they reach the database and authenticated on read, so a tampered row fails loudly rather than decrypting to nonsense. A stolen copy of the database is not a stolen set of LinkedIn accounts.
• Passwords hashed with scrypt. Salted per user, n=2^14. Not recoverable by us. A wrong password and a missing account take the same time, so neither can be told from the other.
• Account isolation enforced in one place. Every account's reach is computed by a single function and every route asks it. The test suite enumerates every route the application exposes and attacks each one with an identity that must not reach it — a route added later without a check fails without anyone remembering to test it.
• Refusals never confirm what exists. An account you may not see and an account that does not exist return the same status and the same words.
• Append-only audit log. Nothing in the system updates or deletes an audit row. Who approved, connected, changed or erased what, and from which address.
• Sign-in throttled two ways. On the address and on the network address separately, so one attacker cannot lock every account out and a botnet cannot walk through.
• Cross-site request forgery closed twice. A session cookie that is HttpOnly and SameSite=Lax, and an origin check on every state-changing request.
• Deletion on a schedule, not on read. A row filtered out of a query is still a row in the file. The retention sweep deletes, and /api/retention shows whether anything is overdue.

Annex III — sub-processors

Authorised under Clause 9, Option 2, as at the date of this page.