App Data Annex

Soverain s.r.o. Last updated: 8 October 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 and team timesheet

OnTask is a personal work clock and a team timesheet for Jira Cloud. Its global page (Apps → OnTask) has two tabs, one for each. Focus 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. Team shows the time that people you select logged in Jira worklogs, per day, over a period you choose. The Team tab is on for every site, with no admin switch, and anyone with OnTask on the site can open it. An OnTask panel also appears on every issue view.

The Team tab reads worklogs in the viewer's browser, as the viewer, so Jira's own permissions decide what each viewer sees. It adds them up on every load and stores none of it. There is no manager role and no privileged view: everyone sees the same tab, and nobody gets a view of a colleague that the colleague's own peers could not also open. OnTask's own records about a person — their running clock, their ranking and the score behind it, their settings, their session history, the summaries they typed and their saved views — are never shown to anyone else. The worklogs OnTask writes are ordinary Jira worklogs, though, so their issue and duration can appear on a colleague's Team tab like any other worklog that colleague can see. The worklog comment, which may hold the person's summary, is never shown there.

Reading colleagues' logged time is workplace monitoring. Your organisation is the controller for that use, needs a lawful basis for it, and must tell its staff where the law requires it — §4.4 of the Privacy Policy and §2 of the DPA.

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.

The Team tab added no scope. It uses read:jira-work and read:jira-user, which OnTask already requested, for the Team purposes named above. It makes six calls, all reads and all from the viewer's browser as the viewer: the issue search (POST /rest/api/3/search/jql) and the worklog reads (GET /rest/api/3/issue/{id}/worklog) and the browse-users check under read:jira-work; the viewer's own profile (GET /rest/api/3/myself), the people search (GET /rest/api/3/user/picker) and the name lookups (GET /rest/api/3/user?accountId=) under read:jira-user.

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 or avatars, and no other profile data, are ever persisted. Every name and avatar OnTask shows, on the Team tab and in its people search too, is read from Jira into the viewer's browser or into one response, shown, and discarded. A saved view holds account IDs, not names. This is a real difference from Kanban+ (§3), which does store display names.

No one's logged time is stored. The Team tab computes its figures in the viewer's browser each time it loads, and discards them.

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.

A half-written summary is not stored at all. It stays on the stop screen while you are typing it, and closing that screen loses it. An earlier version of this annex described an "unsent draft" kept for seven days; the app has never written one, and the row has been removed rather than the feature added.

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

Saved Team views: not aged out. A view is kept until its owner deletes it, their data is erased, or a site administrator erases everyone's data. It holds account IDs, a period and a name, and no time. The people in it are taken out automatically by the same erasure that removes the rest of their data, including when their account closes, and a view left with nobody in it is deleted. Saving over a view that has changed since it was opened is refused, so a page that was open before someone's erasure cannot put that person back into the view.

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 erasure is licence-gated on the server. Delete my OnTask data is also on the lock screen shown when a subscription lapses; Delete everyone's is not, because that screen replaces Settings & privacy, so an administrator who needs it then should write to support@soverain.cz.

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 the stored account IDs to Atlassian's Personal Data Reporting API (manifest scope report:personal-data), those reported longest ago first; a daily job then erases the accounts Atlassian reports as closed. The account IDs reported include everyone inside a saved view, not only the people who saved one. A weekly run has a time limit, so on a very large site the accounts it does not reach lead the next run and are reported every second week rather than every week. An erased person is removed from every saved view, and a view left with nobody in it is deleted. A view's name is its owner's own text and is not rewritten, so it can still mention them. 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, durations and short reasons, 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