ENETDocumentation is only available in English.
Marketplace (opens in a new tab)

Privacy and data handling

Version 1.0, effective 09.09.2026.

This notice covers Work Item Selector for Jira. It does not cover oktul.com, which has its own privacy policy. They answer different questions, and one document covering both would be vague about each.

Every fact below is taken from the application’s own Forge manifest and source, and each one names where you can check it yourself.

Who is responsible for what

For anything this application touches inside your Jira site, you are the controller and Oktul is the processor. That is not a formality. You decide what data exists and who may see it, and your own retention and access policies govern it. Oktul processes it only to make the application work, on your instruction, and has no independent right to use it.

  • Processor: Oktul OÜ (English rendering Oktul LLC), registry code 17589681, Seebi tn 1-703, 11316 Tallinn, Harjumaa, Estonia
  • Data protection contact: hello@oktul.com
  • Security and support: the Help Center, or support@oktul.com

The Article 28 terms for that processing are the data processing addendum, which is published rather than sent on request and is incorporated into the application licence. You do not have to ask for it, and your reviewer can read it during the evaluation rather than after it. It carries the sub-processor position, the audit rights, the deletion terms and the breach clock, all of which apply to this application.

Two addresses, and they are not interchangeable. hello@oktul.com is where a data protection request goes and a person reads it. Anything with a response target measured against it — a support request, a vulnerability report — belongs in the Help Center or at support@oktul.com, which open a request in the same service desk. We publish no privacy@ or security@ alias, because an address that bounces is worse than one that is shared: a subject-access request sent to a dead alias gets silence rather than an answer.

Where Oktul is the controller instead

Two things do not run through the roles above, and both are covered by the website privacy policy rather than by this notice:

  • The Marketplace licence record Atlassian passes us when you install or subscribe — the organisation, the site, the tier, the licence dates and a technical contact. You did not send it to us, so it is Article 14 information and that policy sets it out in full.
  • A support conversation you start with us, with the retention periods stated there.

What leaves your Jira site

Nothing. That is a technical fact rather than a reassurance, and you can check it yourself in two places.

The application’s Forge manifest declares no permissions.external of any kind and no remotes. Those are the only two ways a Forge app can reach the network, so their absence is not a policy we could quietly change without you seeing a new permission request. Specifically, there is:

  • no analytics, telemetry, usage measurement or crash reporting
  • no error-reporting service
  • no third-party script, tag or pixel
  • no sub-processor, because there is no data flow for one to sit in

The declared permissions are visible on the Marketplace listing under Permissions, and in manifest.yml in the application’s own repository.

There is also no Oktul infrastructure in the path. No Oktul server, no Oktul database, no log Oktul can read, and no console through which anyone here could look at your data even if asked.

This is a per-application answer

Egress is decided per application. Some Oktul applications will need it for a feature to work at all, and where that happens it is stated on that application’s own page with the recipient named. A company-wide claim of “no egress” is one we would eventually have to break, so we do not make one. See how we handle data.

Where the data lives

Everything is stored in your own Atlassian tenancy, in two places:

What Where Why there
The work items a field holds The Jira custom field value It is the field’s value. This is the only source of truth.
The relationship index A Jira issue property, workItemSelection, on both ends So “what does this point at” and “what points at this” are both answerable without scanning every work item.
Field configuration Forge storage (storage:app) The JQL scope, the columns, the permission mode and the link settings for each field context.

Data residency is your Atlassian setting, not ours. Because nothing leaves your tenancy, everything follows the residency you have configured for Jira Cloud. We cannot move it and cannot be asked to.

What personal data is involved

None is persisted by this application.

Account ids and display names are read to run a query or draw a column, used inside that one request, and written nowhere. A column showing several people is cut server side to the three the card actually draws, so nobody who is not displayed is transmitted to the browser at all.

The relationship index holds work item keys. It holds no names, no account ids and no free text.

Permissions it requests, and why

Seven scopes. Each is requested because a named feature needs it.

Scope Why it is requested
read:jira-work Run the JQL scope query and read the fields a card draws.
write:jira-work Save a selection, maintain the relationship index, and keep a native work item link in step.
read:jira-user Draw the assignee and other user columns as avatars.
manage:jira-configuration Read the field context configuration and the site’s field catalogue.
storage:app Store each field context’s own configuration.
read:cmdb-object:jira Resolve an Assets object to its label so it can be shown as a column. Every call is optional and failure is silent, so a site without Assets is unaffected.
read:servicedesk-request Answer “which requests are this person’s” on the Jira Service Management portal, as the customer.

Two of these deserve their own explanation, because a reviewer will ask.

manage:jira-configuration is the broad one. It is needed to read app field context configuration and the site’s field catalogue. Atlassian offers granular replacements, and migrating to them is planned.

read:servicedesk-request exists because a portal customer holds no Jira application access. Their call to Jira’s search endpoint is answered with an HTML error page, so the Service Desk customer API is the one surface they can call as themselves. It is used only for a caller Jira has already refused to search as, and only to establish which requests are theirs: the ones they raised, the ones they participate in, and the ones shared with their organisation. No Jira platform endpoint exposes that last one.

Three things we disclose rather than let you discover

The brief this application is built to says these must be stated first. They are not defects; they are consequences of what the features do, and a reviewer who finds them later is right to distrust everything else on the page.

  1. IGNORE_USER shows work items across project boundaries. When an administrator chooses that permission mode, the picker searches with the application’s permissions rather than the viewer’s, so a person can select work items they cannot normally browse. What that exposes is exactly the columns the administrator configured, and nothing else. RESPECT_USER is the recommended mode and searches as the viewer. Anonymous portal visitors carry no account at all and are always restricted, whatever the mode says.
  2. JQL search suggestions return keys only, never summaries. Atlassian requires that request to run with application permissions, and it cannot be filtered to the person typing, so it would otherwise leak summaries. Returning bare keys is the deliberate limit.
  3. The Automation action writes as the application. A change no person made is therefore not recorded against a person, and the write is not limited to what the rule’s owner can see. The field’s JQL scope is the control on that.

The JQL scope is a selection constraint, not an access control

The scope defines what the picker offers. It does not restrict what the field can hold. A value written through CSV import or the Jira REST API can store a work item the picker would never have offered, because those paths do not go through the picker.

Use Jira’s own project and issue-level permissions for access control. Use the scope to keep a picker useful.

How long it is kept

For as long as the application is installed, and no longer. Retention after uninstallation is zero days.

The number is stated plainly because the Marketplace listing’s Privacy and Security tab asks for a maximum retention period after uninstall, and the honest answer here is nothing rather than a duration.

Uninstalling removes the custom field type, and Jira removes the stored values with it, as it does for any custom field. Export anything you need first. Forge storage goes with the application.

Because all of it lives in your tenancy, deletion is your action rather than a request you make of us. There is nothing to keep afterwards: no copy outside your instance, no backup, no anonymised extract.

Your rights, and how to exercise them

Under the GDPR you have the right of access, rectification, erasure, restriction, objection, and data portability.

For data inside your Jira site, exercise these with your own organisation, because it is the controller. Your Jira administrators can read, correct and delete anything this application stores, using the same tools they use for the rest of the site. Coming to us first adds a step and cannot produce a faster answer.

Where Oktul is genuinely the controller — the Marketplace licence record and a support conversation, as set out above — write to hello@oktul.com. A person reads it, and you get an answer within one month, as Article 12(3) requires. If a request is complex we may extend that by up to two further months and will tell you inside the first month if we do.

Where you need our help answering a request about data inside your own site, ask through the Help Center and we will provide it without charge. The data processing addendum is what commits us to that.

No automated decision-making. Nothing this application does produces a decision about a person within the meaning of Article 22, and there is no profiling. The picker returns what your JQL scope and your permission scheme allow, and a person chooses from it.

If you believe we have handled something wrongly, you can complain to the Estonian Data Protection Inspectorate, which supervises Oktul, or to your own supervisory authority.

Security

The application runs on Atlassian Forge, which provides tenancy isolation and encryption at rest and in transit. Because there is no Oktul infrastructure in the path, there is no Oktul attack surface to compromise and no Oktul credential that could be used against your site.

What we have been assessed against

Oktul holds no audited certification. There is no ISO 27001 and no SOC 2, and we say so rather than implying one.

What exists instead is a published self-assessment for this application: Work Item Selector is listed in the Cloud Security Alliance STAR Registry at Level 1, which is the completed CAIQ Lite questionnaire, all 138 questions across the 17 Cloud Controls Matrix domains, readable by anyone without asking us. Level 1 is a self-assessment and not an audit, and the security assessment page says so at the top. The company carries a separate entry at the same level, scoped to Oktul rather than to any application.

The distinction is the point: a self-assessment is worth exactly what its answers are, which is why they are published in full rather than summarised into a badge.

Reporting a vulnerability

Reports go to the Help Center, or to support@oktul.com if you would rather write an email. Both open a request in the same service desk, so the report carries a reference and a response target measured against it. We answer within 24 hours, Monday to Friday, we tell you what we found, and we credit reporters by name unless asked not to. There is no paid bounty, and we say so rather than implying one exists.

We will not bring or support a claim against you for good-faith research, where you avoid privacy violations and service degradation, act only against your own installation and its data, give us reasonable time to fix what you find before disclosing it, and do not exploit the issue beyond what is needed to demonstrate it. If a third party brings a claim about such research, we will make it known that it was authorised. The same undertaking is in the application licence.

Security testing of a Forge application is testing of Atlassian’s platform too, so it follows Atlassian’s own policy rather than a permission we can give.

How quickly a vulnerability gets fixed

Remediation targets are published by severity in the service level agreement, scored by CVSS rather than by our opinion of the finding. They are shorter than the timeframes Atlassian requires of a Marketplace cloud app in every band, which is a comparison you can check rather than a claim you have to take:

Severity Oktul publishes Atlassian’s Marketplace requirement
Critical, CVSS ≥ 9.0 7 calendar days 10 days
High, CVSS ≥ 7.0 14 calendar days 4 weeks
Medium, CVSS 4.0 to 6.9 28 calendar days 12 weeks
Low, CVSS < 4.0 56 calendar days 25 weeks

Atlassian’s figures are its Security Bug Fix Policy for cloud apps, which applies to this application whatever we publish. Where the two differ, the shorter one is what we are held to.

If something goes wrong

We have had no security breach or incident to date. Where one affects customer data we process for you, the data processing addendum commits us to telling you without undue delay and within 24 hours, with what we know, what we are doing and what we recommend you do. Whether it is notifiable to a supervisory authority is the controller’s judgement, which is yours, and we do not make it for you.

When this notice changes

The version and date at the top change with it, and the change is recorded in the release notes. A change to what data is collected, where it goes or who can see it is called out there explicitly rather than folded into a list of fixes.

Version 1.0 on 09.09.2026 is the first version published without a draft marker. It added the data processing addendum as the Article 28 contract behind the roles stated here, separated the two addresses and what each is for, named the Marketplace licence record as the second thing Oktul controls, gave retention after uninstall a number, added the vulnerability safe harbour and the remediation targets, and corrected a security section that said Oktul publishes no assessment while this application’s CAIQ Lite answers were already in the STAR Registry.

A problem or a question? Write to support@oktul.com or open a request in the Help Center. Both reach the same service desk, so either way the request gets a reference and an SLA measuring the response.