Security & Sub-processor Statement

Soverain s.r.o. Last updated: 6 September 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 — a personal work clock for Jira — has the same shape. 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.

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 are both eligible for the Atlassian Runs on Atlassian programme. 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.

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 — is made as you (Forge asUser), with your own Jira permissions, so it cannot see or change anything your account could not. 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.

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 and no other profile data: every name it shows is looked up for that response and discarded.

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 two deletion paths and the personal-data reporting and erasure jobs are deliberately not licence-gated: a lapsed subscription does not stop you deleting your data.

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 and durations only — never a storage key, a stored value, an account ID or a raw error. The one line beyond that 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.

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 and your clock 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