App Data Annex

Soverain s.r.o. Last updated: 6 September 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 apps are shaped differently enough that each is documented separately: sections 1–7 cover Kanban+, section 8 covers Diagon, section 9 covers OnTask. Each Soverain app is documented here rather than getting its 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.

Closed accounts. A weekly job reports every stored account ID to Atlassian's Personal Data Reporting API (manifest scope report:personal-data); a daily job then erases closed accounts from board configuration, team rosters and the active-board pointer, and refreshes changed display names from Jira. Its state lives under the privacy: key prefix and is included in the full purge. Neither job is licence-gated: a lapsed subscription does not pause erasure.

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 FastSpring 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 FastSpring and by us — the buyer email and order identifiers — sit outside the app entirely and are covered by the Privacy Policy. Write to privacy@soverain.cz about those.

9. OnTask — personal work clock

OnTask is a personal work clock for Jira Cloud. A global page (Apps → OnTask) lists your own assigned issues, ranked by a deterministic score; you start a clock on one; stopping it writes a native Jira worklog authored by you. An OnTask panel also appears on every issue view. There is no team view, no manager report and no aggregate: the app never shows one person's OnTask data to another person.

It is a Forge app, like Kanban+, and shares the same platform boundary: no Soverain servers, Atlassian as the only sub-processor, all data in Forge hosted storage inside your installation. Where sections 1–7 already give the answer, this section points at them instead of repeating them. Where OnTask differs — no display names stored, no write to Jira except the one you confirm, nothing generated — it says so.

Summary

Permissions the app requests

OnTask requests five scopes. As with Kanban+, they define what the app can read — a wider boundary than what it stores.

Data the app STORES

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

No display names, and no other profile data, are ever persisted. Every name OnTask shows is looked up from Jira per response and discarded. This is a real difference from Kanban+ (§3), which does store display names.

Data the app ACCESSES but does NOT store

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

Retention decisions worth explaining

Session history: 12 months, at most 400 entries a month. The history is what the Today list and the daily-total check are built from. Twelve months is a real, statable number rather than "indefinitely"; the cap of 400 entries a month bounds how much any one account can accumulate. The worklogs themselves live in Jira and are unaffected by the history expiring.

Submission record: 30 days. This record exists to make "you confirmed once" mean "exactly one worklog exists". It is written before the worklog call is made; if the outcome of that call is ever unclear, the app reconciles against the record and against the small ontask property carried by the worklog itself, rather than retrying blind. Thirty days is far longer than any reconciliation needs, and after that the record has no job left.

Unsent draft: 7 days. A half-written summary is kept for a week so that an interruption does not lose it. After a week it is stale rather than useful, and it goes.

Running clock: not aged out. It is deleted when you stop or discard it, not on a timer.

Retention is enforced by a daily job. The job can read Jira — to ask whether an account still exists — but it is structurally unable to write to Jira. No background process in OnTask can.

Deletion and uninstall

None of these touches Jira. The worklogs and comments OnTask created are ordinary Jira data authored by you; they stay in Jira after any OnTask erasure and after uninstallation, and are removed, if at all, the way any other worklog or comment is removed in Jira. Neither delete button is disabled when a subscription lapses.

Like Kanban+, OnTask implements no uninstall-time cleanup hook, deliberately, for the reasons given in §6. Anyone who wants the data gone before uninstalling uses the delete buttons first.

Closed accounts. A weekly job reports every stored account ID to Atlassian's Personal Data Reporting API (manifest scope report:personal-data); a daily job then erases the accounts Atlassian reports as closed. Failures stay queued and are retried; accounts whose data is already gone are dropped from the bookkeeping. Atlassian's "updated" signal — a profile changed — is deliberately not acted on, because OnTask holds no copy of any profile to refresh. As a backstop, the daily job also makes a bounded per-account check of whether the account still exists. Neither job is licence-gated: a lapsed subscription does not pause erasure.

Data residency — in scope and out of scope

Section 7 applies to OnTask unchanged.

IN SCOPE — pinned to your Atlassian data residency location: every OnTask record listed above, and all Jira data the app reads. The app holds nothing outside Forge hosted storage, so every piece of customer data OnTask handles is in scope. There is no second copy anywhere.

OUT OF SCOPE: no app data. The four items in the §7 table — application logs, compute location for individual invocations, Marketplace licence and transaction records, support correspondence — sit outside pinning for OnTask for exactly the reasons given there. On logs specifically: OnTask's log lines carry counts and durations only, so what Atlassian's logging platform holds about an OnTask installation names no person.

Not applicable: OnTask has no realm-migration obligations of its own. When Atlassian moves your site between regions, its data moves with it; there is no Soverain-side step.

Related: Privacy Policy · Data Processing Agreement · Security Statement