Data processing agreement

This is the agreement under Art. 28 GDPR between you, as the controller, and us, as the processor, for the part of Culma we operate: the server your devices synchronize through.

It is unusually short, and the reason is the architecture rather than brevity for its own sake. A processor that receives your notes in readable form has to promise a great deal about what it does with them. This one receives sealed bytes and holds no key to them, so most of what such a document usually contains does not apply — and what remains can be stated exactly. Where something is a limit rather than a promise, it is written as one.

1. The parties

Processor

ZNIPP GmbH
Underschwändlistrasse 10
6048 Horw
Switzerland

Company number CHE-105.642.181, commercial register of the canton of Lucerne. Contact for everything in this agreement, data protection included: contact@znipp.ch, +41 41 589 80 75. There is no separate data protection officer; we are below the threshold that would require one, and the address above reaches the person who built the system.

Controller — you: the organization, practice, firm or person who decides what goes into the vault.

2. How this becomes binding

Write to contact@znipp.ch and we will send this document for signature, in German or English, as a PDF or for your own signing tool. We counter-sign within two working days.

If your procurement requires your own template, send it. We will read it and tell you plainly which clauses we cannot meet and why — a processor our size that signs a document it cannot perform is worse for you than one that says so.

Until it is concluded, the terms and the privacy notice govern, and the facts in sections 3 to 12 below are true whether or not anything is signed.

3. What we process for you

Subject matter and purpose. Operating the Culma server so that your devices can find each other and so that a copy of your vault exists when a device is lost. Nothing else. We do not analyze, profile, index, train on or derive anything from what you store.

Duration. For as long as we provide the service to you, plus the retention in section 12.

Nature of the processing. Storage, transmission and deletion of encrypted records, and the message passing that lets two of your devices reach each other.

What the server stores, exactly:

What	What we can read
Note content, titles, paths, folder names, whiteboards, attachments, view state	Nothing. Every key is derived on your devices; none reaches us. Titles and folder names are sealed with the content
Vault membership and roles	Nothing. Who belongs to which vault is in the vault, sealed, not in a database of ours
The address of each sealed record, its kind, its size and its arrival time	That something changed, how much of it there was, and when. A size is a fingerprint of a sort, and we would rather say so than let you discover it
Device identifiers, and the public half of the key a seat is bound to	That a given device synchronized, and that a seat was presented
Connection metadata and IP addresses, in the ingress access log	That an address connected, and when

Categories of personal data in the content, and categories of data subjects: determined by you and unknown to us. Culma is used by lawyers, physicians, therapists, works councils and journalists, so the content may include data under Art. 9 GDPR and material under professional secrecy — which is precisely the case the encryption is for. We cannot tell, and we do not need to.

What we do with it: store it, serve it back to your devices, delete it when you or this agreement say so.

4. Your instructions

We process only on your documented instructions. Using the service is the instruction: the operations available to your devices are the operations we perform. Anything beyond them — and there is very little we could do beyond them — needs an instruction in writing to the address in section 1, and we may charge for work it causes.

If an instruction appears to us to infringe data protection law, we will say so and may suspend it until you confirm it (Art. 28(3), final sentence).

The honest limit: many instructions a controller may wish to give are impossible here rather than refused. We cannot search your content, correct a record inside it, export it in a readable form, or hand it to you decrypted — we have never held the key. Section 9 says what that means for a data subject's request.

5. Confidentiality

Everybody who can reach the systems on which your records are stored is bound to confidentiality beyond the end of their engagement and is instructed on the obligations in this agreement. At the date of this document that is one person, the managing director, which we state rather than imply through a sentence about "authorized personnel".

6. Security of the processing (Art. 32)

The measures below are the ones that matter here. They are properties of the design rather than policies laid over it, which is why they can be described concretely.

Encryption. Content is encrypted on your devices before it reaches us, under keys derived on those devices. The key hierarchy is per vault and per shared folder, with a separate key per note derived from its folder's; each stored record is sealed with authenticated encryption that binds its type and key generation, so a record cannot be silently moved or reinterpreted. Removing somebody from a vault or a folder mints a new key generation and re-seals what the remaining members hold. Device-local state files that would otherwise reveal titles or paths are themselves sealed to the device.

Pseudonymization. What the server addresses is opaque: a bucket identifier and a meeting point derived from keys we do not hold, a device identifier, a public key. Nothing in the server's own records names a person, a company or a file.

Access control. The server will not accept writes to a keyed store without a valid admission token, and the tokens are issued without our learning which device asked for one, so a payment and a stored record cannot be set side by side. Administrative access to the host is limited to the person in section 5, over authenticated connections only.

Integrity. A record is written and synchronized to disk before it is acknowledged. Every record is authenticated on read; one that does not authenticate is reported rather than used, and reclaiming disk space is verified rather than assumed. A record that cannot be accounted for is set aside, not destroyed.

Availability and resilience. Every one of your devices holds a complete, authoritative copy of the vault, which is what makes the server a convenience rather than the system of record: if it is unreachable you keep working, and synchronization catches up. Restoring a vault therefore does not depend on us — a total loss of the server costs synchronization, not data, which is the opposite of the usual arrangement and worth checking against whatever else you are comparing. Your sealed bytes are held on a volume in the data center named in section 8, and every record is written and synchronized to disk before it is acknowledged.

Transport. Everything between your devices and the server runs over TLS.

Separation. The commercial records — who pays, for what plan — contain no vault, folder or storage identifier, and the server that holds your bytes never receives a billing address. We do not yet claim that the two run on separate infrastructure, because they do not.

Deletion. See section 12, including the four limits in section 9.

What is not in place, stated because you will ask. No ISO 27001 or BSI C5 certification. No independent security review or penetration test has been published; the key model and the protocol are documented and you are welcome to read them, and we will not use the word audited until a report exists and is published with its findings. We will tell you when that changes rather than waiting to be asked again.

7. Sub-processors

You give us general written authorization to engage sub-processors. Today there is one:

Sub-processor	Where	What for
Hetzner Online GmbH	Germany — servers in Falkenstein, Saxony	the machines the server runs on

That is the whole list for this service. There is no content delivery network — the search and dictation models are downloaded from your own server or from ours, never a third party's — no analytics provider, no error reporting service and no hosting outside the entry above.

Before we add or replace one we will tell you at least 30 days beforehand. You may object on reasonable data protection grounds; if we cannot accommodate the objection, you may terminate the affected service and we will refund the unused part of what you have paid. A sub-processor is bound to obligations no weaker than those in this agreement, and we remain liable to you for its performance.

8. Where the data is, and transfers

The server runs at Hetzner in Falkenstein, Germany. We are established in Switzerland, and administration happens from there.

For a controller in the EU or the EEA, that means one transfer: to us, in Switzerland. The European Commission has recognized Switzerland as providing an adequate level of data protection, confirmed in its review of 15 January 2024, so no standard contractual clauses are required for it. We use no sub-processor controlled from outside Europe for this service.

For a controller in Switzerland, this agreement is also the agreement under Art. 9 FADP, with the same content, and the German processing location needs no further instrument.

Should a government or court demand data from us, we can hand over only what we hold: ciphertext, opaque addresses, sizes and timings. We will tell you of any such demand unless the law forbids it. This is a cryptographic position, not a jurisdictional claim — we make no promise about what any country's law does or does not allow.

9. Helping you answer a data subject

A data subject's request reaches you, not us, because the content is yours and only you can read it. We will help with anything that depends on what we hold, free of charge and without undue delay.

Four limits, which are properties of the system and would be true of any honest description of it:

• A purge record persists. When a note is destroyed, the fact of its deletion and its identifier remain, because a device that was offline across the deletion would otherwise bring the note back. The content is gone; the record of the deletion is not.
• In a shared folder, a purge is not a recall. On the device of a member who never saw that note reach the trash, the file moves to their trash instead of being destroyed, so that unsynchronized work is not lost. Your storage is freed and our copy is gone; nobody's machine is reached into.
• There is no crypto-shredding. A note's key is derived rather than stored, so there is no key we could throw away to make an existing copy unreadable. Deletion has to be deletion of bytes.
• Destroying something at the server is not instant. For 30 days the sealed bytes are set aside where our operator — never a key of yours — can put them back, and then they are deleted. It exists because an owner who turned against the other members could otherwise destroy a shared folder's history for everybody, and the server cannot tell that act from an ordinary deletion. The bytes stay sealed throughout, so nobody reads them in the meantime, ourselves included. It also means the 90-day window above is followed by this one: a lapsed vault's copy is gone within 30 days of the end of it.

These four decide what an erasure request can actually achieve, so they are here rather than discovered during one.

10. If something goes wrong

We will inform you of a personal data breach affecting your processing without undue delay and at the latest within 48 hours of becoming aware of it, with what we know, what we do not yet know, and what we are doing — so that you can meet your own 72-hour duty under Art. 33.

What a compromise of the server would expose is ciphertext, addresses, sizes and timings: material, and not content. We will say so in those terms rather than softening it, and we will not describe an incident as harmless because the content was sealed.

11. Audits and information

You may satisfy yourself that we are doing what this document says.

• We answer security questionnaires and written questions, and we will give you the architecture documentation the design is specified in.
• We will confirm in writing the facts in sections 3 to 12 as they stand at the date you ask.
• Where you are legally required to inspect on site, we will arrange it by appointment, limited to what is necessary and at your cost. We are a very small company and an inspection is an expensive event for us; we would rather answer in writing, and we say so openly instead of burying a refusal in a clause.

12. The end of the processing

When this agreement ends, or when you ask:

• Return is not something we can do, and it is also not something you need: the vault on your devices is the complete, authoritative copy, in Markdown and SVG files in your own folder. There is nothing to export and no fee to leave.
• We delete the copy we hold. On a lapsed subscription it stays readable for 90 days and is then deleted, which is a published commitment so that nobody loses their only copy at the moment an invoice is missed; you may ask us to delete it sooner and we will. A deletion at the server sets the sealed bytes aside for 30 days first — the fourth limit in section 9 — so a vault is gone from our disks within 30 days of the deletion, and we will confirm the date.
• The purge record in section 9 survives, as does what the access log in section 3 holds until it expires.
• We will confirm the deletion in writing on request.

13. What this agreement does not cover

Your billing data — your name, your email address, your country, what you bought. For that we are not your processor but a controller in our own right, and the sale is made by Paddle.com Market Limited as merchant of record, which is itself a controller for the transaction. What is held, why, and for how long is in the privacy notice; Paddle's own notice covers its half. No mail sender or payment service touches the processing this agreement is about.

What runs on your own devices. Search, semantic search, dictation and everything else computes locally; we are not involved in it and no processing agreement is needed for it.

A server you run yourself. With an on-premise license there is no processing by us at all, and this agreement does not apply.

14. Liability, precedence, law

Each party is liable as data protection law provides. Our liability to you under the contract is as stated in the terms, section 15; nothing here limits a data subject's rights or our liability under Art. 82 GDPR.

Where this agreement and the terms conflict on the processing of personal data, this agreement wins. Where it conflicts with a signed copy of your own template, the signed document wins.

Swiss law applies, and the courts of Lucerne have jurisdiction, as in the terms — with the GDPR as the material standard for everything in this document and the mandatory provisions of your own country's law untouched.

To conclude this agreement, or to ask anything about it: contact@znipp.ch.