A privacy claim is only as good as the list behind it, so here is ours, field by field. Certain content you put into the Dekimu ecosystem is encrypted in your own browser to your vault key — we call that sealed — and our servers store it only as ciphertext. Your IBAN is sealed. So are the tax IDs, payment references, file names and dispute notes you enter in InvoiceUp, the document drafts you save to your miniterms vault, and the details of a data subject request once you seal it. In Hub, content is sealed wherever you use your vault.
A sealed field is encrypted in your browser, with a key from your vault, before it leaves your device. What travels to us, and what sits in our storage, is ciphertext. Your vault is part of your Dekimu ID account and opens with your Dekimu ID password; we store the vault key only in encrypted form. The practical upshot: for sealed content, someone who obtains a copy of our stored data, through a breach for example, finds ciphertext for that content, not your words.
When your vault is created you are shown a 24-word recovery phrase, once. Write it down somewhere safe. If you reset your password without it, your vault stays locked to the old password, and you recover it in Dekimu ID with the recovery phrase or your previous password. Without either, sealed content cannot be recovered — by you or by us. That is the trade-off of sealing, and it's the reason the phrase matters.
Some data has to be readable by our servers for the product to work, and we'd rather list it than blur it. Across the ecosystem, your account email and your own legal name, Tax ID, address and country are readable, because invoicing and identity need them. In InvoiceUp, amounts, due dates, invoice notes and client emails stay readable so reminders can run. Some InvoiceUp flows also receive fields in readable form instead of sealed: invoice import, e-invoice intake, actions taken from Hub, and the v1 API — including the Tax ID and the payment reference. In Hub, accounts and paths without a vault are readable. In miniterms, everything other than vault-saved drafts and sealed request details is readable. Readable data is still protected by encryption in transit and at rest, and by access controls; it just isn't sealed.
Sealing everything sounds stronger and works worse. An early version sealed the business name, and a contract went out signed "Personal Workspace" because the server building the document couldn't read it. Encrypting that field protected very little and broke something real. So your public business identity — the details that already appear on every invoice you send — stays readable, and the fields listed above are sealed where you use the vault. The full list lives in our Data Processing Agreement, and it's the version that binds us.
"Encrypted" is a word. A list of exactly which fields are sealed, and which aren't, is a claim you can check.
Updated November 2026. An earlier version of this post described the sealing more broadly than it applies. This version names exactly what is sealed and what is readable, matching the current Data Processing Agreement. When that line moves, this post and the agreement move together.