Privacy Policy

Soverain s.r.o. Last updated: 6 September 2026 Effective: 1 September 2026

1. Who we are

Soverain s.r.o. ("Soverain", "we", "us") is a limited liability company registered in the Czech Republic.

Soverain is established in the European Union, so we have not appointed an Article 27 representative. We are not required to appoint a Data Protection Officer under Article 37 GDPR and have not done so; privacy questions go to the address above.

2. What this policy covers

This policy covers all Soverain s.r.o. products, services and websites, including:

• the soverain.cz website;
• Kanban+, our Atlassian Forge app for Jira Cloud, distributed through the Atlassian Marketplace;
• OnTask, our second Atlassian Forge app for Jira Cloud — a personal work clock that logs time to Jira — also distributed through the Atlassian Marketplace;
• Diagon, our desktop diagramming app for Windows and Linux (macOS in development), sold by subscription through the soverain.cz website;
• any future Soverain product, unless that product publishes its own policy.

Field-level detail for Kanban+ and OnTask — exactly which fields each app touches and how long they are kept — is in the App Data Annex, which forms part of this policy. OnTask stores little enough that §4.3 of this policy also lists all of it, with retention. Diagon needs no such annex: it keeps your work on your own computer, and §5.2 covers the little we receive when you subscribe.

3. The two roles we play

Data protection law distinguishes the party who decides why data is processed (the controller) from the party who processes it on someone else's instructions (the processor). Soverain is in different positions depending on the data. Read both sections — they are not alternatives.

Diagon sits outside both buckets for the work itself. Your diagrams, your source files and the bundled AI all stay on your own computer — none of it is sent to us, so there is no role for us to play over it. The only personal data a Diagon subscription creates is what buying one creates, and there we are the controller. See §5.2.

We do not claim to collect no personal data. That claim would be false, and stating it would itself breach the fairness and transparency principle in Article 5(1)(a) GDPR. Section 5 sets out precisely what we receive.

4. Bucket A — data Kanban+ and OnTask handle inside your Atlassian environment

Here Soverain is a processor. You are the controller. This section covers both of our Forge apps. Most of it is true of both in exactly the same way; where the two differ, we say so.

4.1 Where they run and where they stay

Kanban+ and OnTask are both Forge apps. Forge is Atlassian's own application platform. In practice this means, for each of them:

• The app runs exclusively on Atlassian-hosted compute and storage. For Kanban+ and OnTask Soverain operates no servers, no databases, no analytics pipeline and no data warehouse. (We do run soverain.cz and a licence endpoint for Diagon; neither is reachable from either Forge app, and the Forge apps make no outbound calls at all.)
• The app declares no remotes and no external permissions in its manifest. It makes no outbound HTTP requests of any kind. There is no code path by which app data leaves the Atlassian environment. OnTask goes as far as bundling its typefaces rather than loading them from a font service.
• App data is written to Forge hosted storage, which sits inside your Atlassian installation.
• Consequently the app inherits your Atlassian data residency. If you have pinned your Jira Cloud site to a region, app data at rest follows that pinning.

Both apps are eligible for the Atlassian Runs on Atlassian programme, whose requirements are that apps use exclusively Atlassian-hosted compute and storage, support the host product's data residency, and give customers admin control over external egress.

4.2 What Runs on Atlassian does not mean

We would rather you hear the limits from us than find them in a security review:

• Residency covers data at rest, not every execution. Atlassian's Forge documentation is clear that residency pinning governs where data is stored, and that an app invocation may sometimes execute from a location other than the host region. We deliberately do not reproduce Atlassian's wording here — it is revised from time to time, and a stale quotation in our policy would be worse than none. The current text in Atlassian's own data residency documentation is the one that governs.
• It constrains plumbing, not permissions. Runs on Atlassian limits where data can go. It does not limit what the app is allowed to read inside your Jira. That is governed by the scopes you approve at installation, which are listed in the App Data Annex for both apps — OnTask's five are also set out in §4.3 below. Atlassian states plainly that these controls "do not prevent misuse of access granted to the app during installation".
• It is not a security certification. It is a platform-architecture programme. See our Security Statement.

4.3 What the apps store

Kanban+ stores board configuration and derived scheduling data. Some of it is personal data. The complete, field-level list is in the App Data Annex. In summary, the app durably stores:

• Atlassian account IDs and display names — for board administrators, team rosters, saved-view filters and automation "assign" actions, and the account ID of the administrator who last verified a board's permissions.
• Retrospective content — free text written by your team members on retrospective boards, stored with the author's display name and account IDs for votes.
• Jira issue summary text — for cross-board blocker links only. Issue summaries can contain names and confidential project detail.
• Issue identifiers and status timestamps — used to calculate service-level metrics.
• Board names, automation rule names and audit entries — text your administrators write.

The great majority of Jira data Kanban+ displays — issue descriptions, comments, attachments, worklogs, changelogs, avatars — is read into your browser, rendered, and discarded. It is never written to app storage.

OnTask is a personal work clock. It shows you your own assigned issues in a ranked order, you start a clock on one, and when you stop it and press Log it the app writes a native Jira worklog in your name. It stores much less than Kanban+, and this is all of it (§9 of the App Data Annex records the same inventory in the annex's own format):

The personal data in that table is Atlassian account IDs and the free-text summaries people write about their own work. The summaries are the sensitive part: a per-person, timestamped record of what someone worked on, in their own words. OnTask stores no display names and no other profile data — every name you see in it is looked up from Jira for that one response and discarded. That is a real difference from Kanban+, which does store display names.

One person's OnTask data is never shown to another person by the app. There is no team view, no manager report and no aggregate; the app has nothing of that kind to show.

OnTask asks for five permission scopes at installation, and every call it makes to Jira on your behalf is made as you, with your own permissions — it cannot read or write anything you could not:

• read:jira-work — your assigned issues, their fields, their comments (to spot mentions you have not answered), existing worklogs, and the "may I log work here" check;
• write:jira-work — creating the worklog you confirm and the optional issue comment; only from the stop screen after you press Log it, never in the background;
• read:jira-user — your own profile (your timezone, for the worklog start time), and whether an account still exists, which drives automatic erasure;
• storage:app — Forge hosted storage on your site;
• report:personal-data — Atlassian's Personal Data Reporting API, required because account IDs are stored.

What OnTask writes into your Jira. Two things, both authored by you and both shown to you before they happen. The first is a worklog — duration, start time and, if you choose, your summary as the worklog comment. It carries a small ontask worklog property holding the submission ID, which is what makes duplicate prevention exact. The second is an issue comment, written only when you tick the box — it is off by default — and previewed byte for byte along with who will be notified: your words verbatim plus the duration and the issue key, nothing generated. A site administrator can switch comments off for the whole site without uninstalling. Once written, worklogs and comments are ordinary Jira data, and no OnTask erasure deletes them.

4.4 Purposes and legal basis

We process Bucket A data only on your documented instructions, which are given by your installation and configuration of the apps and by our DPA. The purposes are: for Kanban+, providing the board, timeline, reporting, automation and service-level features you configured; for OnTask, ranking each user's own assigned issues, running their clock and writing the worklog they confirm.

The legal basis for that processing is yours to determine as controller — typically legitimate interests under Article 6(1)(f) in running your own project management and recording the work done on it. We do not select a legal basis on your behalf.

We do not:

• sell, rent or share your data;
• use your data to train machine-learning models;
• use your data for advertising or profiling;
• access your Jira data for our own purposes.

5. Bucket B — data Soverain actually receives

Here Soverain is the controller. This is the section most self-written Forge privacy policies omit. It is the section reviewers check.

5.1 Marketplace licence and transaction records

When you buy or evaluate Kanban+ or OnTask, Atlassian is the seller of record. Atlassian bills you, collects any VAT, and pays us. We never invoice you and never see your payment card or bank details.

Atlassian does, however, give us partner reports about our own licences. From those reports we receive:

Atlassian sets the exact column set of these reports and revises it from time to time, so the table describes what they contain in substance rather than promising a fixed list of columns. We request nothing beyond what Atlassian provides to every Marketplace partner about its own licences.

The contact names and email addresses are personal data about your staff, not about your company. That is why this section exists.

Purposes: managing our licence and billing relationship with Atlassian; providing support; sending service-critical notices (security issues, breaking changes, end-of-life notices); understanding which editions are in use so we can plan development.

Legal basis: Article 6(1)(f) GDPR, legitimate interests — operating and supporting a software product we license to you, and communicating with the people you nominated as our contacts. We have balanced this against your contacts' interests: the data is limited to business contact details voluntarily nominated for exactly this purpose, and we use it only for the product they administer.

Marketing: we do not send marketing email to Marketplace contacts. If that ever changes it will be on a separate opt-in basis under Article 6(1)(a) — we will not quietly repurpose an address you gave us for administration.

5.2 Diagon subscriptions and licence keys

Diagon runs on your computer. Your diagrams, your files and the bundled AI stay there; none of it reaches us. For 30 days from first run you can use the whole app without an account, an email address or a card — during the trial we receive nothing at all.

When you subscribe, FastSpring is the seller of record. FastSpring — Bright Market, LLC d/b/a FastSpring (Santa Barbara, California, USA) with its affiliates, including FastSpring B.V. (Amsterdam, the Netherlands) — sells you the subscription, takes the payment, calculates and remits the tax, issues your invoice and pays out refunds. Your card or bank details go to FastSpring, never to us: we cannot see them and store nothing of them. FastSpring decides for itself how it processes what you enter at checkout, as its own controller, and its privacy notice governs that part.

What FastSpring passes on to us is deliberately small:

We use it for two things: minting your licence key and supporting you afterwards. The key is a short signed string that embeds your email address, the transaction reference and an expiry date. Your address is inside it on purpose — it is what makes a key traceably yours, and a shared key obvious. The key is delivered by email through Azure Communication Services (Microsoft, EU data location), sent from noreply@soverain.cz; replies reach hello@soverain.cz.

We keep no customer database. When your copy of Diagon checks that the subscription is still running, our endpoint asks FastSpring in that moment and mints a fresh key from the answer — nothing about you is stored on our side to make that work. What does persist is a server log line for each licence mint, recording the buyer email, the order reference and the key issued, so that support can re-send a key that went astray.

Purposes: delivering and renewing the licence you paid for, and supporting you. Legal basis: Article 6(1)(b) GDPR, performance of our contract with you — a licence key cannot be issued or delivered without an address to put in it and send it to. The mint log line rests on Article 6(1)(f), our legitimate interest in being able to re-send a key and match it to a payment. Retention: see §8.4.

Cancelling, updating a card and downloading invoices all happen in FastSpring's self-service portal at soverain.onfastspring.com/account, also reachable from any FastSpring receipt email. Refunds are covered by our Refund Policy.

5.3 Application logs (Kanban+ and OnTask)

This one is easy to overlook, so we state it explicitly.

Forge apps write diagnostic log lines. Atlassian collects them and makes them available to the app developer. Per Atlassian's documentation, log access is enabled by default when a customer installs an app, a site administrator can disable it, and logs are retained for 30 days and then deleted. Retention is set by Atlassian and we cannot extend it.

Kanban+ writes log lines for its scheduled jobs and automation runs. These deliberately record counts, dates, identifiers and Jira issue keys. Error handlers log only the error's message (err?.message), not the whole error object, so an error that carries request or response context cannot place Jira issue content or a user display name into logs. One honest limitation remains:

• Some log lines still include customer-authored names — board names and automation rule names. In practice such names sometimes contain a person's name (for example a board called "Adam's sprint board").

Why that limitation is still here. Atlassian's own logging guidance says names and user-generated content should not be logged, and we agree. An earlier and worse problem — whole error objects being logged, which could drag Jira content along with them — has been fixed: the scheduled-job and automation code now logs only the error message. The board and rule names are what is left, and we intend to remove them too. Until they are gone this paragraph stays as written, because we would rather over-disclose than describe a cleaner app than the one you installed.

OnTask holds the stricter line from the start. 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 limitation described above for Kanban+ does not arise in OnTask: it has no boards or rules for anyone to name.

Purpose: diagnosing faults and keeping the apps working. Legal basis: Article 6(1)(f), legitimate interests in operating reliable software. Retention: 30 days, enforced by Atlassian. We do not export logs to any external system.

If you would rather we saw no logs at all, your Jira site administrator can disable app log access in the Atlassian admin console. Both apps continue to work; we simply lose diagnostic visibility.

5.4 Support correspondence

If you email support@soverain.cz we receive your email address, your name if you give it, and whatever you put in the message — which may include screenshots, Jira extracts or Diagon files you choose to attach.

Purpose: answering you. Legal basis: Article 6(1)(f), legitimate interests in supporting our customers; and Article 6(1)(b) where you are contracting with us directly. Retention: we keep a support thread while it is still useful — while the question is open, while the same problem may come back, and while a claim arising from it could still be made — and delete it when it is not. We do not copy support mail into any other system, and you can ask us to delete a thread sooner.

5.5 The soverain.cz website

The pages you read are statically rendered. The site sets no advertising or tracking cookies, stores nothing in your browser, embeds no third-party analytics, and shows no consent banner because there is nothing non-essential to consent to. The only cookies anywhere on this site are ones a visitor never receives: signing in to our owner-only statistics page sets App Service authentication cookies (a session cookie and its short-lived login helpers) in the browser of that signed-in administrator alone.

The site runs on Microsoft Azure App Service in the EU. Like any web server it records standard access logs, including visitor IP addresses, which we use for security and reliability.

If you start a Diagon purchase, the checkout is FastSpring's. Clicking a buy button loads FastSpring's Store Builder Library script from sbl.onfastspring.com and opens FastSpring's checkout window — that script is not loaded until you click, so reading the site involves no third party at all. Once you are in the checkout, FastSpring's own privacy notice and cookies apply to it.

We do count visits, but we do it ourselves and without touching your browser's storage. §5.6 describes exactly what that means and what it records.

5.6 Analytics

We want to know whether anyone reads this site, so we count visits. We built the counter ourselves rather than buying one, which let us leave out every part we did not need.

No cookies, and nothing left behind on your device. Nothing is written to your browser — no cookie, no localStorage, no sessionStorage, no fingerprinting script, and no identifier of any kind. Nothing survives the page being closed, because there is nothing to survive. The page on which we read these counts is a different matter, and §5.5 names it: signing in to that owner-only statistics page sets App Service authentication cookies for the signed-in administrator only; they are never set on a visitor's browser.

No third party. The counter is our own code, running on our own Azure App Service, writing to a table in our own Azure Storage account in the EU. No request goes to any analytics vendor, and there is nothing for anyone to resell.

What the page reports, in full. Opening a page sends us three things:

• the path you are on, with any query string dropped;
• the referring site's host — the host only, never the full URL — and only on the page you arrive at. Read a second page and that field is empty, so this tells us how many arrivals came from elsewhere, not how many pages you then read;
• two facts about how the page is being drawn: whether your browser is set to a dark or a light theme, and whether the window is wide enough for the drawing's margin rails to show. Those two are things the page asks your browser, and we would rather name them than let "we read nothing from your device" stand as a claim we cannot make. Neither identifies you, neither is unique to you, neither is stored anywhere on your device, and both end up as a tally.

Your language (cs, en) is not asked of the page at all — we take it from the Accept-Language header your browser was already sending with the request. A counted click adds one thing more: which of about ten named things was clicked, such as a download button.

What a row contains. One row per page view or counted click: the fields above, whether the user agent looks like a phone, and the time of the visit — the row is stamped with the moment, not merely the day. Plus a sixteen-character visitor code, which is the next paragraph.

No IP address is stored, and the code dies with the day. Your IP is used for one thing, in memory, and then discarded: it goes into a SHA-256 hash together with your user agent and that day's salt, and only the first sixteen characters come out and are written down. That string tells us two page views were the same visitor within a single day. It tells us nothing else, and it is not sent back to your browser.

The salt is the part that carries the promise. It is a random value our code generates at the start of each UTC day, uses for that day only, and destroys the following day. We keep no copy anywhere. Once it is gone, that day's codes cannot be recomputed — not by us, not by anyone who obtains the table, and not by anyone who compels us to produce what we hold, because we no longer hold it. So a code written on Monday cannot be matched to a code written on Tuesday. That is not a statement about our restraint; it is arithmetic, and it is the reason we designed it this way rather than keeping one long-lived secret and asking you to trust us with it.

Do Not Track and Global Privacy Control are honoured. If your browser sends DNT: 1 or Sec-GPC: 1, we record nothing — no row, no code, no log line. The request is turned away before anything is read out of it, whether or not the signal binds us legally.

How long we keep it. Thirteen months — 400 days — and then the row is deleted automatically. Nothing is archived anywhere first, and the day salts are deleted on the same schedule if any survived that long.

Why there is no consent banner. §89(3) of Czech Act No. 374/2021 Coll. on Electronic Communications — the act that replaced No. 127/2005 Coll. and has governed this since 2022 — is about storing information on your device and gaining access to information stored there. We store nothing there. What the page does ask your browser is named above: two display settings, neither identifying, neither persisted, neither leaving this site. There is no identifier that outlives the day, no profile being assembled, and nobody it is shared with — so there is nothing here on which a meaningful choice could be exercised, and we would rather not put a banner in front of you to harvest one. If you want out anyway, the two signals above are honoured. If the design ever changes, this paragraph changes with it.

What we do with it. We look at totals — visits per day, which pages are read, which downloads are clicked — to decide what the site should say next. Nothing is used to target advertising, nothing is sold, nothing is shared, and nothing here is a decision about you within the meaning of §10.

The legal basis is our legitimate interest (Article 6(1)(f) GDPR) in knowing whether our own website works. The balancing is straightforward, because the design gives us the count without giving us the person: there is no identifier that survives the day, and nothing that follows you to another site.

6. Who else sees your data

6.1 Sub-processors (Bucket A)

One: Atlassian.

That is the entire list. Kanban+ engages no analytics provider, no error-tracking service, no CDN of our own, no email provider that touches app data, and no AI or machine-learning service. OnTask's sub-processor list is the same single name, Atlassian: its storage is Atlassian's Forge hosted storage inside your own site, and it makes no network call to anything but Atlassian.

Diagon has no sub-processors either, for the simplest possible reason: the app does its work — including the AI — on your own machine, so there is nothing for a sub-processor to be given. The providers involved in buying Diagon are recipients of purchase data, and they are named in §6.2.

An earlier version of Kanban+ included an optional AI assistant that called an external API. It has been removed in its entirety — the feature, the code that could store an API key, and the outbound network permission. The app now makes no external calls.

We maintain the sub-processor list in the Security Statement and will notify customers before adding a new one, as required by our DPA.

6.2 Recipients (Bucket B)

• Atlassian — as the seller of record for Kanban+ and OnTask and the source of our licence reports.
• FastSpring — Bright Market, LLC d/b/a FastSpring, with its affiliates, including FastSpring B.V. (Netherlands) — as the seller of record for Diagon subscriptions. FastSpring holds the payment details, issues the invoice and pays out refunds; we receive from it only what §5.2 lists.
• Microsoft — Azure hosts the soverain.cz website and the licence endpoint, and Azure Communication Services (EU data location) delivers licence emails.
• Our mailbox provider — support and privacy correspondence sits in our @soverain.cz mailboxes.
• Our accountant and tax advisers — for statutory bookkeeping. What reaches them are the payout and settlement statements we receive from Atlassian and FastSpring; we do not hand them customer contact lists.
• Public authorities — where we are legally obliged to disclose.

We do not sell personal data and have never done so.

7. International transfers

App data (Bucket A) stays within the Atlassian environment and follows your Atlassian data residency configuration. Soverain does not transfer it anywhere. Diagon's own data never leaves your computer, so there is nothing to transfer.

For Bucket B, both Atlassian and FastSpring are global companies and our commercial relationships with them may involve transfers outside the EEA — FastSpring's principal entity is in the United States. Those transfers run on the providers' own transfer mechanisms, including Standard Contractual Clauses, set out in the data processing terms each of them publishes. Website hosting and licence email delivery are on Microsoft Azure in the EU.

8. How long we keep things

8.1 App data (Bucket A)

You control this. Both apps also enforce their own retention.

Kanban+

Why issue status timestamps are not aged out. Each record holds the moment an issue entered its current status. That is the input to every service-level calculation. A long-running issue legitimately has a months-old timestamp, so deleting records by age would silently produce wrong service-level reporting rather than reclaim dead data. We judged silent corruption of your reports to be worse than retaining a small identifier record. The records contain an issue ID, an issue key, a status ID and a timestamp. They name no person.

Deleting a board now removes that board's audit log, its snapshots and its cross-board blocker records as well as the board itself. Earlier versions removed only the board row.

OnTask

A daily job enforces these limits. It can read Jira — to ask whether an account still exists — but it is structurally unable to write to Jira. The worklogs and comments OnTask has written are Jira's own data and follow your Jira's retention, not OnTask's.

8.2 What happens when you uninstall

We want to be precise, because the honest answer is that Atlassian performs this deletion, not Soverain. We hold no copy to delete.

• Atlassian documents that Forge hosted storage retains data for 28 days after uninstallation, during which the data is first soft-deleted and then disposed of in line with Atlassian's retention and disposal policy as described in its SOC 2 report.
• If you reinstall, Atlassian treats it as a new installation — but if you ask within 21 days of uninstalling, Atlassian can relink the new installation to your old data.
• If your Atlassian site is permanently deleted, all associated app data is deleted with it.

Neither Kanban+ nor OnTask implements an uninstall-time cleanup hook, deliberately. That is a decision, not an oversight. Atlassian already deletes the data; the only available hook (preUninstall) is documented as non-blocking, so any promise built on it would be one we could not keep; and eagerly wiping storage would destroy your 21-day relink window. If you want OnTask's data gone before you uninstall, use the delete buttons described in §8.3 first.

8.3 Erasure on request, without uninstalling

Atlassian provides no way for a site administrator to clear an app's storage while keeping the app installed. We built that missing control ourselves, in both apps. Kanban+ contains a full-purge function that deletes every record the app holds for your site. It requires Jira site-administrator rights and an explicit confirmation.

Current limitation, stated plainly: the purge exists in the app backend, refuses to run for anyone who is not a Jira site administrator, and requires an explicit typed confirmation — but no user interface for it has shipped yet. Today, a customer who wants a full erasure without uninstalling should email support@soverain.cz and we will walk your site administrator through running it. We intend to ship a self-service control, and this paragraph will change on the day it exists, not before.

OnTask ships both controls in its interface, under Settings & privacy. Delete my OnTask data erases your own data — any user, no administrator involved. Delete everyone's erases every record the app holds for the site; it is for Jira site administrators only, the check is made server-side, and it fails closed. Neither button is disabled when a subscription lapses. Neither touches the worklogs or comments OnTask wrote into Jira — those are ordinary Jira data now, and deleting them is done in Jira.

Closed Atlassian accounts are erased automatically. Once a week Kanban+ reports every Atlassian account ID it holds to Atlassian's Personal Data Reporting API. When Atlassian answers that an account has been closed, the app removes that person from every record it stores — board administrator and viewer lists, team rosters, saved-view filters, automation "assign" actions, permission-verification records, retrospective votes and authorship, and the per-user active-board pointer — in its next daily run. When Atlassian answers that a profile has changed, the stored display name is refreshed from Jira. This runs whether or not the site's subscription is active, and it does not depend on anyone asking.

OnTask does the same, with one difference. Weekly it reports every account ID it holds; daily it erases the data of accounts Atlassian reports as closed, retries any erasure that failed, and drops from its bookkeeping accounts whose data is already gone. As a backstop it also runs a bounded per-account check that the account still exists. The difference: when Atlassian answers that a profile has changed, OnTask does nothing, because it holds no copy of any profile to refresh. Neither job depends on the licence.

8.4 Data we control (Bucket B)

9. Where our information about you came from

(Article 14 GDPR — required where we did not get the data from you directly.)

If you are named as a technical or billing contact for a Kanban+ or OnTask licence, we did not get your name and email address from you. We received them from Atlassian, drawn from the contact details recorded against your organisation's Marketplace licence. The categories are set out in §5.1.

If you bought a Diagon subscription, we received your email address from FastSpring, the seller of record, because you gave it at FastSpring's checkout rather than to us. The categories are in §5.2.

Likewise, personal data appearing in Kanban+ storage (account IDs, display names, retrospective text) originates from your employer's Jira instance, not from you directly. For that data your employer is the controller and Soverain is a processor. The same holds for what OnTask stores — your account ID and the work summaries you typed into it: they live in your employer's Atlassian site, your employer is the controller, and Soverain is a processor.

10. Automated decision-making

We carry out no automated decision-making producing legal or similarly significant effects, and no profiling, within the meaning of Article 22 GDPR.

Kanban+ generates board insights and forecasts. These are deterministic calculations over your own Jira data — rule-based, not machine learning — and they inform your team, not us. Since the removal of the AI assistant the app contains no model inference of any kind.

OnTask ranks your own assigned issues by a deterministic score, tuned by six sliders you set yourself. It is arithmetic over your own Jira data, it is shown to you alone, and it decides nothing about you.

Diagon does bundle an AI model, which turns a description you type into diagram code. It runs on your own computer, on your own text. We never see the prompt or the result, it makes no decision about you, and it is not used to profile anyone.

11. Your rights

Where Soverain is the controller (Bucket B), you have the right to:

• access the personal data we hold about you;
• rectify inaccurate data;
• erase data ("right to be forgotten");
• restrict processing;
• data portability;
• object to processing based on legitimate interests — including an absolute right to object to direct marketing;
• withdraw consent at any time, where we relied on consent, without affecting prior processing.

Email privacy@soverain.cz. We respond within one month, extendable by two further months for complex requests, and we will tell you if we need the extension. We do not charge for this unless a request is manifestly unfounded or excessive.

Atlassian also operates a "right to be forgotten" flag for Marketplace contacts. Where a contact exercises it with Atlassian, the contact fields in our reports are replaced with an RTBF marker.

Where Soverain is a processor (Bucket A), address your request to your own organisation — your employer or the Atlassian customer whose Jira site you use — because they are the controller. If you contact us directly we will forward the request to them and assist as our DPA requires.

For OnTask you need not ask anyone: Delete my OnTask data, under the app's Settings & privacy, erases everything it holds about you (§8.3).

Complaints

You can complain to your local supervisory authority. Ours is:

Úřad pro ochranu osobních údajů (Office for Personal Data Protection) Pplk. Sochora 27, 170 00 Praha 7, Czech Republic +420 234 665 111 · uoou.gov.cz

We would appreciate the chance to resolve it first, but you are not required to come to us before going to the ÚOOÚ.

12. Security

Summarised here, detailed in our Security Statement: Kanban+ and OnTask run on Atlassian infrastructure and inherit its security controls, have no external network access, and store no credentials; access to our Marketplace partner account is protected by multi-factor authentication. OnTask additionally confines all writing to Jira to a single source file that only the confirm-and-log step may use, so none of its background jobs can write to Jira, and worklog creation is built so that one confirmation can never produce two worklogs. On the Diagon side, our FastSpring credentials are held in Azure Key Vault rather than in the application, licence keys are signed server-side with a key that is never shipped to the desktop app, and the licence webhook accepts only requests carrying FastSpring's cryptographic signature.

We will notify affected customers and, where required, the ÚOOÚ, of a personal data breach within the timeframes set by Articles 33 and 34 GDPR. Our processor-side breach obligations are in the DPA.

13. Children

Our products are business tools sold to organisations. They are not directed at children and we do not knowingly process children's data.

14. Changes to this policy

We will update this policy as our products change. The "Last updated" date at the top always reflects the current version.

For material changes we will give notice before the change takes effect — by email to the technical and billing contacts on record and to Diagon subscribers, and by a notice on this page. Where a change materially affects how a Marketplace app handles end-user data, we will also notify Atlassian, as the Atlassian Developer Terms require.

From the next version onwards we will list dated changes at the bottom of this page. Any superseded version is available from privacy@soverain.cz on request.

15. Contact

Soverain s.r.o. Chabařovická 1324/21, Kobylisy, 182 00 Praha 8, Czech Republic Privacy: privacy@soverain.cz · Support: support@soverain.cz IČO 29693144 · DIČ CZ29693144 (not registered for VAT) · File C 450889, Municipal Court in Prague

Related: App Data Annex · Data Processing Agreement · Security Statement · Refund Policy · Support