App Data Annex

Soverain s.r.o. Last updated: 3 August 2026

This annex forms part of the Soverain Privacy Policy. It records, per app, exactly which personal data categories the app touches, whether the app merely accesses the data or durably stores it, and how long stored data is kept.

Everything below is derived from each app's source code, not from a questionnaire.

Apps in scope

The two apps are shaped so differently that they are documented separately: sections 1–7 cover Kanban+, section 8 covers Diagon. Future Soverain apps will be added here rather than getting their own privacy policy.

1. Kanban+ — summary

2. Permissions the app requests

You approve these at installation. They define what the app can read — a wider boundary than what it stores.

3. Data the app STORES

Everything in this table lives in Forge hosted storage, inside your Atlassian installation, subject to your data residency configuration.

Browser storage

One key, kanban:collapsedCols, in the browser's local storage. It records which board columns you collapsed. No personal data. It never leaves your device.

4. Data the app ACCESSES but does NOT store

Read from Jira, rendered in your browser, then discarded. Never written to app storage, never transmitted anywhere.

5. Retention decisions worth explaining

Analytics snapshots: 365 days. The product surfaces at most 90 days of history. A year is generous headroom while still being a real, statable number rather than "indefinitely".

SLA cooldown markers: 48 hours. The marker's purpose expires after 24 hours. 48 gives margin for clock skew and delayed scheduled runs.

Issue status timestamps: not aged out. Each record holds the moment an issue entered its current status — the input to every SLA calculation. A long-lived issue legitimately has a months-old timestamp, so age-based deletion would silently corrupt your SLA reporting instead of reclaiming dead data. The record names no person.

Known minimisation gap, disclosed rather than hidden. The app writes a status-timestamp record for every issue on the Jira site that changes status, not only issues on a Kanban+ board. An installation with one board covering one project still accumulates one small record per site-wide issue. Narrowing it to board-relevant issues is a product change rather than a retention one — issues would carry no timing history until a board covering them existed — and we would rather describe the current behaviour plainly here than quietly alter what your SLA reports are built on. As it stands, each record is a few fields naming no person, and it is removed by the full purge in §6 and by uninstallation.

Board deletion cascades. Deleting a board now also deletes its audit log, its snapshots, its cross-board blocker records, and any user's pointer to it. Earlier versions deleted only the board record itself, orphaning the rest.

6. Deletion and uninstall

Kanban+ implements no uninstall-time cleanup hook, deliberately. Atlassian already performs the deletion; the only available hook is documented as non-blocking and could not support a reliable promise; and wiping storage eagerly would destroy your 21-day relink window.

7. Data residency — in scope and out of scope

Runs on Atlassian requires apps to support the host product's data residency. Here is what that covers for Kanban+.

IN SCOPE — pinned to your Atlassian data residency location

• All Kanban+ records listed in §3, stored in Forge hosted storage.
• All Jira data the app reads, which never leaves your Atlassian environment.

Because the app holds no data outside Forge storage, every piece of customer data the app handles is in scope for data residency. There is no second copy anywhere.

OUT OF SCOPE — not covered by data residency pinning

Stated because Runs on Atlassian obliges us to be specific, and because these are the items an enterprise reviewer will ask about:

Not applicable

Kanban+ has no realm-migration obligations of its own: it stores nothing outside Forge hosted storage, so when Atlassian moves your site between regions the app's data moves with it. There is no Soverain-side migration step.

8. Diagon — desktop app

Diagon is a different shape of product from Kanban+. You install it on your own computer and it runs there. There is no Soverain server holding your diagrams, because no server is involved in making them.

Summary

Data the app STORES on your computer

Nothing in that folder is transmitted anywhere except the licence key, and only as described next.

Data the app SENDS

Licence refresh — the signed key, and nothing else. While the app is online with an active subscription, it sends its current licence key to soverain.cz so a fresh one can be issued for the new period. The request carries the key and nothing more: no diagram, no filename, no file path, no machine or hardware identifier, no account. Our server verifies the key's signature, asks Paddle whether the subscription is still running, and hands back a replacement key. As with any web request, our server sees the connecting IP address and a timestamp in its ordinary logs. Everyday licence checks — is this key genuine, has it expired — need no network at all: they are done against a public key built into the app.

Icon URLs you write yourself. If one of your diagrams references an image by URL, Diagon fetches that image from the host you named so it can be drawn and included in exports. That request goes to that third party, not to us, and only because your diagram asked for it. A diagram with no icon URLs makes no requests at all.

Deletion

Delete a diagram file and it is gone — it was only ever your file. Removing the app's application-data folder clears the licence key, the trial and licence state, and the preferences; your diagrams are untouched, because they were never inside it. The purchase records held by Paddle and by us — the buyer email and transaction identifiers — sit outside the app entirely and are covered by the Privacy Policy. Write to privacy@soverain.cz about those.

Related: Privacy Policy · Data Processing Agreement · Security Statement