Security & Sub-processor Statement

Soverain s.r.o. Last updated: 8 October 2026

Written for security reviewers and procurement teams. It says what our architecture guarantees, and — just as importantly — what it does not.

The short version

We ship three products in two shapes.

Kanban+ runs entirely inside your Atlassian environment. We operate no servers, no databases and no data stores for it. The app makes no outbound network calls. Your Jira data never reaches Soverain infrastructure.

OnTask has the same shape. Its global page is one page with two tabs: Focus, a personal work clock for Jira, and Team, a day-by-day view of the time the people you pick have logged in Jira; an OnTask panel on every issue view shares the same clock. It runs entirely inside your Atlassian environment, on the same Forge platform, and makes no network call to anything but Atlassian — no remote host, no CDN, not even a font service, since its typefaces are bundled with the app. Nothing runs on Soverain-operated servers, because there are none for it. The Team tab's grid runs in your own browser, as you, shows only the worklogs Jira already lets you read, and stores nothing about anyone's time — it is worked out on each load and discarded. What it does store is a saved view: a name, a period and the account IDs of the people you picked, readable only by the person who saved it.

Diagon is a desktop application that runs on your machine. Your diagrams are plain-text files on your own disk. The AI that turns a description into a diagram is bundled with the app and runs locally. The app's only network call is a small licence check to soverain.cz — your content is not part of it.

That leaves the purchase path. Kanban+ and OnTask are sold through the Atlassian Marketplace and billed by Atlassian, so they add nothing to it. Buying Diagon involves a payment processor and an email delivery service, and those are real third parties handling real personal data. They are listed in §3.

For the products themselves, this is not a claim about how carefully we secure our systems. It is a claim that there are no systems to secure — no vendor database holding your content, no misconfigured storage bucket, no leaked backup, no analytics pipeline — because the components that would create them do not exist.

1. Kanban+ and OnTask — Runs on Atlassian

Kanban+ and OnTask both carry Atlassian's Runs on Atlassian trust signal, granted by Atlassian and shown on their Marketplace listings. Its requirements are:

1. 01Apps exclusively use Atlassian-hosted compute and storage.
2. 02Apps support data residency matching the host Atlassian product.
3. 03Customers can control external data egress via admin controls.

What it means concretely for both apps

• Each app's manifest declares no remotes and no external permissions. The Forge platform will not permit outbound requests we have not declared, and we have declared none in either app.
• Kanban+ makes no outbound HTTP request: there is no fetch() call, no HTTP client, and no webhook, Slack or Teams delivery code anywhere in the source. This is not a disabled feature flag — the code does not exist. The app's only network operations are Atlassian's own Forge-brokered Jira calls (requestJira), which never leave your Atlassian environment. (A reviewer grepping the source for fetch will find only internal Jira-read helpers such as fetchLabels, which route through that same Atlassian platform client — not browser or Node fetch.)
• OnTask makes no network call to anything but Atlassian. It declares no remote host and uses no CDN; even its typefaces are bundled with the app rather than fetched from a font service, so a page of OnTask loads nothing from outside your Atlassian environment.
• Both apps store data only in Forge hosted storage, inside your installation.
• A previous version of Kanban+ included an optional AI assistant that called an external API. It has been removed completely: the feature, the outbound network permission, and the code that could store an API key. The app also now proactively deletes any API key a previous version may have stored.

What Runs on Atlassian does NOT guarantee

We would rather state these ourselves than have you find them.

It is not a security certification. It is an architecture programme. It asserts where data can go, not that the app is free of defects.

It does not constrain permissions. It limits egress, not access. Kanban+ and OnTask still request Jira scopes you approve at installation, and those scopes are broad by necessity — read:jira-work means either app can read issues your user can read. Atlassian is explicit that these controls "do not prevent misuse of access granted to the app during installation or abuse of the app runtime." Evaluate each scope list on its own merits. Both are in the App Data Annex. One thing OnTask adds to that evaluation: every Jira call it makes on your behalf is made as you, with your own permissions, so its scopes never let it see or change anything your account could not.

Residency covers data at rest, not every execution. Forge data residency is Atlassian's control, not ours — and its exact scope, including when an invocation may execute outside the host region, is defined by Atlassian's own documentation rather than by us. Read Atlassian's current residency documentation for the authoritative statement. We would rather point you at it than paraphrase it.

Logs are outside the residency boundary. See §5.

2. Diagon — a local desktop app

Diagon is a desktop app for Windows and Linux (macOS in development). It is diagrams-as-code: you write text, the app renders a diagram.

• Your documents stay on your disk. They are plain-text files in a format you can read, diff and version-control yourself. We never receive them.
• The AI is bundled and local. The model ships inside the app and runs on your own machine. What you type, the diagram source and the generated output never leave it: there is no inference API, no cloud fallback, no telemetry on what you generate.
• One network call. The app contacts soverain.cz to check and renew its licence. That request carries what is needed to validate the licence — never your documents.
• No account inside the app. No login, no sync, no cloud workspace, no crash-reporting service, no analytics.
• Licence keys are verified offline, using an Ed25519 signature, so the check does not put us in the path of the app starting.

Because we hold nothing of yours, there is no Soverain-held copy of your diagrams to breach, subpoena or lose.

3. Sub-processors

Three — and they do not overlap. One serves Kanban+ and OnTask; two exist only so you can buy and license Diagon.

Neither Kanban+ nor OnTask has a sub-processor other than Atlassian; what they store sits in Forge hosted storage as part of your own site. Diagon's product data has no sub-processor at all, because none of it leaves your machine. FastSpring and Microsoft appear only in the purchase path: taking the payment, minting a licence key, and emailing it to you.

We use no analytics provider, no error-tracking service, no CDN of our own, no AI or ML service, and no hosting provider that holds your Jira data or your diagrams.

The DPA lists only Atlassian, and that is the same answer seen from a narrower angle: the DPA governs the personal data we process on your behalf, which only Kanban+ and OnTask hold, so only their sub-processor appears there. FastSpring and Microsoft handle purchase data, for which we are the controller rather than your processor.

We give 30 days' notice before adding a sub-processor, by email to registered contacts and by updating this page. See §6 of the DPA.

Our providers' assurances are theirs, not ours

Because all Kanban+ and OnTask processing happens on Atlassian infrastructure, the underlying infrastructure controls are Atlassian's — including its SOC 2 reporting, ISO certifications and Cloud Security Alliance registration, available from the Atlassian Trust Center. The same holds for Microsoft's and FastSpring's own certifications and compliance programmes.

We do not claim any of them as our own. Soverain holds no independent security certification. If that ever changes, this section will say so.

4. Application security

Kanban+

Authorisation. The app respects Jira's permission model: users see only what Jira lets them see. Board management is restricted to a board's designated administrators (or a Jira site administrator). Destructive operations — full data purge — require Jira site-administrator rights, checked against the Jira permissions API (/rest/api/3/mypermissions) as the calling user so the UI cannot spoof them, plus an exact confirmation phrase echoed back in the request. Board administrators deliberately cannot trigger a site-wide purge; that would be a privilege escalation.

Acting as the app. Automation rules, the hourly SLA checker and the daily snapshot and dependency scans run in the background with no user session, so they call Jira as the app. Before they may, the app verifies — at the moment a board's projects, filter, columns or rules are saved, using the saving administrator's own permissions via the Jira permissions API (/rest/api/3/mypermissions) — that that administrator holds, in every project the board covers, each permission the rules need (browse, assign, edit, comment, transition, create). A save the administrator is not entitled to is refused, the board's filter is test-run as that administrator, and the verification is recorded on the board. At run time the app only acts where that record still matches the board's projects and rules; anything else is skipped and written to the board's audit log. Boards saved before this check existed are flagged in the app as unverified until an administrator re-saves them; their existing SLA rules and daily scans keep running in the meantime, so an upgrade does not silently stop a customer's automation.

Credentials. The app stores no third-party API keys, no OAuth tokens and no passwords. Authentication with Jira is handled entirely by the Forge platform.

Data in transit. TLS, provided by the Atlassian platform. The app opens no connections of its own.

Data at rest. Encrypted by Atlassian in Forge hosted storage.

Content security. The app runs in a Forge iframe under Atlassian's content security policy. Because we declare no external permissions, that policy permits no connections to non-Atlassian hosts.

Concurrency. Board records carry a revision counter, so conflicting concurrent edits are detected rather than silently overwritten.

Development. Version-controlled source. Tests, lint and build are run locally before every production deploy — the automated test suite, ESLint over the source and a production build of the front end — and all three must pass before anything ships. Pull requests are required for production changes.

OnTask

Authorisation. Every Jira call the app makes on your behalf — reading your assigned issues, checking whether you may log work on one, writing the worklog, and on the Team tab reading your own profile, checking whether you may browse users, searching for people to add, finding the issues the people you selected logged work on, reading those issues' worklogs and looking up names — is made as you, with your own Jira permissions, so it cannot see or change anything your account could not. Calls from the app's back end use Forge asUser. The Team tab's six calls are made from your browser through Forge's requestJira bridge, which always acts as the signed-in user; they only read, and what they return is added up in the browser and not stored. The Team tab added no scope. The one call not made on a user's behalf is the daily maintenance job's read-only check of whether an account still exists, which runs as the app. There are two deletion paths and they are deliberately separate: "Delete my OnTask data" is available to any user, for their own data, with no administrator involved; "Delete everyone's" is restricted to Jira site administrators, checked server-side, and fails closed.

No manager role. There is no administrator view of other people's work and no privileged reader. Everyone who can open OnTask sees the same Team tab — it is on for every site, with no admin switch — and each person sees only the worklogs their own Jira permissions already let them read, so nobody gets a view of a colleague that the colleague's own colleagues could not also open. The tab never shows the comment text on a worklog, which is where a colleague's written summary of the work would sit. OnTask's own per-person data is still never shown to another person: your ranking and the score behind it, your settings, the summaries you wrote about your own work, your session history and your saved views. 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.

Writes to Jira. Exactly one source file (src/jira/write.js) is able to write to Jira. An ESLint rule restricts importing it to the single resolver that handles the stop screen's Log it button, and we have verified that the rule fires when anything else tries. No background job can write to Jira. The daily retention job can read Jira — to ask whether an account still exists — but is structurally unable to write to it. Everything the app writes into Jira, the worklog and the optional issue comment, is shown to you before it happens and written only after you confirm; nothing is written in the background.

Idempotent worklog creation. One confirmation produces one worklog. A submission record is written to storage before the Jira call; the app reconciles against Jira before writing; the worklog carries a small ontask worklog property holding the submission id, which is what makes duplicate prevention exact; after the write it checks for a twin; and nothing is blindly retried.

Credentials. The app collects no Personal Access Tokens, no passwords and no shared secrets, and stores no OAuth tokens or third-party API keys. It holds no credentials at all. Authentication with Jira is handled entirely by the Forge platform.

Data in transit. TLS, provided by the Atlassian platform. The app opens no connections of its own.

Data at rest. Encrypted by Atlassian in Forge hosted storage. OnTask persists no display names or avatars and no other profile data: every name and picture it shows is read from Jira for that one response or that one page and discarded. A saved Team view holds account IDs, a period and a name, and only the person who saved it can see it.

Erasure. Erasing one person deletes only the records that are exactly theirs, so an account ID that happens to begin with another can never reach that other person's data. The same erasure takes the person out of every colleague's saved view and out of the personal-data reporting bookkeeping; if the step that rewrites colleagues' views cannot be finished at the time, the app records it and retries in its daily run. Saving over a saved view that has changed since it was opened is refused and the view is reloaded, so a page left open before someone's erasure cannot put them back.

Content security. As for Kanban+: a Forge iframe under Atlassian's content security policy, which — because we declare no external permissions — permits no connection to non-Atlassian hosts. The app's typefaces are bundled with it, so not even a font is fetched from elsewhere.

Licensing. Enforced server-side in every product resolver, not in the UI. The Team tab's grid is the one feature with no resolver of its own — it reads Jira directly in your browser — so for the grid the licence check is the app's lock screen rather than a server-side gate; either way it shows only what your own Jira permissions already allow. The two deletion paths and the personal-data reporting and erasure jobs are deliberately not licence-gated: a lapsed subscription never stops an erasure from running. Reaching one is a separate matter — the lock screen carries Delete my data, while Delete everyone's sits in Settings & privacy, which the lock screen replaces.

Dependencies. The dependency audit reports 0 vulnerabilities in the front end and 0 in the back end.

Diagon

Authorisation. There is no server-side authorisation model, because there is no server. The app runs as your own user account, on your own machine, and touches the files you point it at.

Credentials. The app stores your licence key. No passwords, no OAuth tokens, no third-party API keys — the bundled AI needs none.

Data in transit. TLS on the licence check. There is no other connection.

Data at rest. Your documents are ordinary files, protected by your operating system's permissions and whatever disk encryption you run. We add no encryption layer of our own, and we would rather say that than imply more.

Licence integrity. Licence keys are Ed25519-signed and verified offline by the app. The private signing key lives in Azure Key Vault, not on a developer machine.

Third-party code in the shipped Forge bundles

For completeness, because a reviewer inspecting our JavaScript bundle will find it: the Kanban+ UI uses the Atlassian Design System component library, which transitively bundles Atlassian's feature-flag client. That client's own endpoints are therefore present as strings in the built bundle. Kanban+ never initialises it — there is no call to it anywhere in our source — so nothing invokes those endpoints.

OnTask's bundle is smaller: it ships React, Atlassian's @forge/bridge client bundled by Vite, and its own self-hosted typefaces.

Independently of that, and more importantly, neither app's manifest declares remotes or external permissions, so the Forge content security policy blocks connections to non-Atlassian hosts regardless of what either bundle contains. We flag the distinction deliberately: the first statements are a reading of our own code, the last is a control the platform enforces whether we read our code correctly or not.

5. Logging — the honest section

This section is about our two Forge apps, Kanban+ and OnTask. Diagon writes its logs to your own machine and sends them nowhere; we never see them.

Forge apps emit diagnostic log lines. Atlassian collects them and makes them available to the app developer.

Kanban+. Its log lines are written to record counts, dates, identifiers and Jira issue keys rather than content. Error handlers log only the error's message (err?.message), never the full error object, so an error that happens to carry request or response context cannot spill Jira content or a display name into logs. One honest caveat remains today:

• Some log lines still include customer-authored board, automation rule and SLA rule names, which in practice sometimes contain a person's name (for example a board called "Adam's sprint board", or a rule named after its owner). Atlassian's own logging guidance discourages logging names and user-generated content. We would rather disclose the gap than describe it away, and we will update this section when the names are stripped.

OnTask. Its log lines carry counts, durations and short reasons — never a storage key, a stored value, an account ID or a raw error, and nothing about whose time is viewed on the Team tab. One line records the licence state (licensed=true/false reason=…), which contains no personal data. The caveat above does not apply to OnTask.

If you prefer that we see no logs, disable app log access in your Atlassian admin console. The apps keep working; we lose diagnostic visibility.

6. Incident response

• We monitor the platform status and security advisories of Atlassian, Microsoft and FastSpring.
• On becoming aware of a personal data breach affecting customer data, we notify affected customers without undue delay and within 48 hours (see DPA §8).
• Notifications describe what happened, what data was affected, likely consequences, and what we are doing.
• Where a breach originates in a provider's platform, that provider may notify you directly under its own agreement with you. We will tell you anything we learn and will not assume you have already been told.

How we handle one. Behind those commitments sits a written incident-response plan, approved 6 September 2026 and reviewed annually and after any incident:

• One person leads every incident from declaration to closure — the jednatel, with no deputy. That is a limitation we state rather than dress up; §7 explains the rest of it.
• A suspected incident is enough to start. Triage — severity, scope, and which of us is controller and which processor — is complete within 24 hours of us becoming aware, on wall-clock time, weekends included.
• For our Atlassian apps we notify Atlassian within 24 hours and keep it updated every six hours until the incident is closed, as the Marketplace partner rules require.
• We notify affected customers within 48 hours, and where we are the controller we notify the Czech supervisory authority within 72 hours, or record why the notification is not required.
• Every incident is recorded in an internal log, from prepared templates, with the evidence and the deadlines met or missed; every one closes with a written review within five working days.
• The plan is exercised, not just written: the first tabletop ran on 6 September 2026 and produced eleven findings and nine dated corrective actions. The next is due by 7 December 2026.

Reporting a vulnerability. Email security@soverain.cz — a monitored mailbox. Tell us what you found and how to reproduce it. We aim to acknowledge within two business days. We will not pursue legal action against good-faith security research that avoids privacy violations, service disruption and data destruction. We do not currently operate a paid bug bounty.

7. Business continuity — stated plainly

Soverain is a one-person company. Enterprise buyers should weigh that.

What reduces the risk:

• Kanban+ and OnTask run on Atlassian infrastructure and keep working without our involvement. If Soverain were unavailable, your boards, your clock and the Team tab keep working; your data stays in your Atlassian installation and remains yours. The worklogs OnTask has written are ordinary Jira worklogs, readable with or without the app.
• Diagon runs on your machine, and its documents are plain-text files you already hold. Nothing you have drawn depends on us being reachable, and any text editor can open it.
• We hold no data you would need to recover from us.
• No proprietary Soverain service sits in the critical path of using Kanban+ or OnTask, or of reading anything you have made.

What we cannot claim: 24/7 staffed operations, follow-the-sun support, or a redundant engineering team. We also hold no source-code escrow and no formal continuity arrangement — procurement often asks, and the honest answer is no, rather than a safety net implied and not built. Our support commitments are the ones we can actually meet — see Support.

8. Compliance summary

Related: Privacy Policy · App Data Annex · DPA · Support