Data & privacy
Last updated: 6 September 2026
Kanban+ is built so that nothing it touches leaves your Atlassian installation. This page describes what that means in practice: where the code runs, what it stores, who can see it, how long it's kept, and how to get rid of it.
For the formal documents, see the Soverain Privacy Policy and the App Data Annex, which records the same facts in the language a DPO expects.
Where the app runs
Kanban+ is an Atlassian Forge app. Its front end runs in a Forge iframe inside Jira; its back end runs on Atlassian-hosted compute; its data sits in Atlassian-hosted Forge storage, inside your installation.
Soverain operates no servers for this app. There is nowhere for your data to be sent, because there is nothing to send it to.
No external network access
The app's manifest declares no remote hosts and no external permissions. Forge enforces that: with no declared remotes, a Forge app cannot make an outbound call to a non-Atlassian host, and one that tried would be blocked by the platform rather than merely discouraged by policy.
In the code, every network call goes through Atlassian's own request helpers to the Jira REST API. There is no fetch to a third-party host anywhere in the app.
Details that fall out of that design:
- Charts are hand-drawn SVG. No charting library, no CDN, no font or asset fetched from outside.
- Opening an issue uses the host's own navigation rather than a link out of the iframe.
- No AI, no model inference. The app previously had an assistant that called an external model; it was removed in full. What's now called the Board Health panel is arithmetic and keyword matching running in your browser, with no network calls at all.
- No Slack, Teams or webhook notifications. Those automation actions were removed for the same reason. Blocker escalation posts a Jira comment instead.
The one CSP relaxation the app requests is inline styles, which the Atlassian Design System components require in order to render.
Permissions the app asks for
You approve these when the app is installed. They describe what the app can read, which is a wider boundary than what it stores.
| Scope | Why |
|---|---|
read:jira-work | Read projects, issues, statuses, fields and dates to draw boards, timelines and reports |
write:jira-work | Transitions, field edits, labels, due dates, sub-tasks, comments and issue links — the changes you and your rules make |
read:jira-user | The user picker for board administrators and team rosters |
read:project:jira | List projects when configuring a board |
read:board-scope:jira-software | Read an existing Jira board's columns when importing it |
read:board-scope.admin:jira-software | Read the filter behind an imported board |
write:board-scope:jira-software | Backlog view: create, start and complete sprints; move issues in and out |
storage:app | Store board configuration in Forge hosted storage |
What Kanban+ stores
Everything below lives in Forge hosted storage inside your installation.
| Record | Contents | Retention |
|---|---|---|
| Board configuration | Name, projects, JQL, quick filters, columns (with WIP and SLA settings), card fields, card colour rules, card aging tiers, saved views, grouping, transition guard, issue templates, timeline bar colours, project colours, custom subpages (including retrospective sticky-note text), administrators (account IDs and display names), the creator's account ID, and the account ID of the administrator who last verified the board's permissions with the time of that check | Until the board is deleted |
| Active board pointer | Which board each person is currently looking at. The key contains an Atlassian account ID | Until the board is deleted, or overwritten on the next switch |
| Teams | Team name and member list (account IDs and display names) | Until the team is deleted |
| Automation rules | Stored inside the board configuration. Rule names and comment text are free text an administrator wrote | Until the board is deleted |
| Automation audit log | Per run: timestamp, rule id and name, trigger type, issue key, each action and its result, duration | The newest 100 entries per board; deleted with the board; clearable on demand |
| Status entry timestamps | Issue id, issue key, status id, and the moment the issue entered that status — the input to every SLA calculation | Life of the installation. Deliberately never pruned; see below |
| Daily snapshots | Per board, per day: how many issues are To Do, In Progress and Done. Aggregate counts only, no issue identifiers | 365 days, then pruned automatically |
| Cross-board blocker edges | Blocked and blocker issue keys, the issue summary text verbatim, blocker status, and board names | Recomputed daily; deleted with the board |
| SLA cooldown markers | A timestamp per rule per issue, so an hourly job doesn't alert 24 times a day | 48 hours, then pruned automatically |
Two of these deserve a second look. Retrospective content is stored inside the board configuration: free text written by team members, attributed by display name, with account IDs recorded as votes. It is the most sensitive text the app holds, because retrospectives are where colleagues write about colleagues. And cross-board blocker edges copy issue summaries verbatim — summaries routinely carry customer names and confidential project detail.
What it does not store
- No Jira issue properties or entity properties. The app writes none, anywhere.
- No custom fields are created in your Jira.
- No payment data, ever. Soverain never sees it.
- No copies of your issues. Issue data is read live from Jira on every view and not cached in app storage. The exceptions are all in the table above, and they are precisely these: audit entries hold an issue key (and no summary); status entry timestamps hold an issue id and issue key — for every issue on the site whose status changes, not only issues on a board; and cross-board blocker edges hold issue keys and the summary text verbatim. Summaries are stored in that last place only.
In your browser, the app stores exactly one thing: which board columns you've collapsed. No personal data.
One minimisation gap, stated plainly
The event listener that records status entry timestamps writes a record for every issue on the site whose status changes — not only issues that belong to a Kanban+ board. The write happens before the board filter is applied.
The stored value names no person: it's an issue id, an issue key, a status id and a timestamp. But it is more data than the app needs, and it is never pruned, because pruning by age would corrupt SLA calculations on legitimately long-lived issues. Narrowing it is a product change, and it hasn't been made yet. The App Data Annex records the same gap.
Who can see what
- Boards are visible site-wide. Everyone who can open the Kanban+ page sees every board on the site, including its configuration and its issues (subject, always, to their own Jira permissions on those issues — the board renders live Jira data fetched as the signed-in user).
- Editing a board is limited to its administrators or a Jira site admin. The check runs on the server against real Jira permissions, so it can't be bypassed from the browser.
- The automation audit log has no permission check. Anyone who can open the page can read it, and it contains free-text rule names and issue keys. Treat rule names as visible to everyone on the site, and don't put anything in one you wouldn't put on a wall.
- Teams are visible to everyone and editable by board administrators and site admins.
- The full data purge requires a Jira site admin plus an exact confirmation phrase.
Identity: who acts
| Path | Acts as |
|---|---|
| Anything you do in the UI — dragging cards, editing issues, bulk actions, escalations, manual snapshots | You |
| Automation triggered by a Jira event | The app |
| The hourly SLA checker, the daily snapshot, the daily cross-board scan | The app |
Changes made by the app appear in Jira's history attributed to the app, not to a person. The app acts only within permissions a board administrator was verified to hold — against their own Jira permissions, in every project the board covers — when the board was saved; see Automation.
Deletion
Delete a board. Removes the board configuration, its audit log, its cross-board blocker records, every one of its daily snapshots, and any dangling active-board pointers other people held on it. You get a receipt of what was removed. Your Jira issues are untouched — the board is a lens, not a container.
Delete a team. Removes that team's record.
Clear the audit log. Board administrators and site admins, per board, on demand.
Automatic pruning. A daily job deletes snapshots older than 365 days and SLA cooldown markers older than 48 hours. It reads and writes only app storage and makes no Jira calls.
Full erasure. A site admin can purge everything the app has stored — every prefix, plus one legacy key left behind by the removed AI assistant. It requires the exact phrase DELETE ALL KANBAN+ DATA, and it's bounded at 2,000 deletions per invocation so a large installation is cleared by running it repeatedly; it's idempotent and resumable. There is no self-service screen for it yet — ask us at hello@soverain.cz and it's run against your installation while the app is still installed.
Uninstalling. Kanban+ deliberately does not wipe its storage on uninstall. Atlassian already deletes Forge hosted storage after an uninstall, and Atlassian gives you a window in which reinstalling relinks your previous data. Wiping eagerly would destroy that window for no gain, and Forge's uninstall hook isn't guaranteed to complete anyway. If you want data gone now rather than on Atlassian's schedule, use the full purge before uninstalling.
Data residency
Kanban+ stores nothing outside Forge hosted storage, so residency follows your Atlassian configuration — it isn't a separate promise Soverain makes on top.
One honest caveat, which the App Data Annex sets out in more detail: the region in which an individual Forge function invocation executes is determined by Atlassian and is not something Soverain controls or is told.
On "Runs on Atlassian"
Runs on Atlassian is a badge Atlassian grants, not one a vendor awards itself. Kanban+ is built to those requirements — Atlassian-hosted compute and storage only, no external egress, no remotes declared — and the code has been checked against that claim. The badge itself has not yet been confirmed by Atlassian, and this page won't claim it until it is.
Related
- Getting started — permissions at install, who can change what
- Automation — what rules record, and who acts when they run
- SLA tracking — where the status timestamps come from
- App Data Annex · Privacy Policy · Security