Version 1.2, effective 28.09.2026.

1. Scope

1.1 This notice describes the processing of personal data by Oktul Work Item Selector for Jira (the “Application”). It forms part of the application licence and is read with the data processing addendum (the “Addendum”). Terms defined in the licence have the same meaning here.

1.2 It does not cover oktul.com or the personal data Oktul processes as a company, which are described in Oktul’s privacy policy.

2. Roles and contact

2.1 For Customer Data processed by the Application, the customer is the controller and Oktul OÜ is the processor within the meaning of Regulation (EU) 2016/679 (the “GDPR”). Oktul processes it only to provide the Application, on the customer’s documented instructions, as set out in the Addendum.

2.2 Oktul, and not Atlassian, is responsible for the privacy, security and integrity of the personal data the Application processes.

2.3 For the licence record Atlassian provides when the Application is installed or ordered, and for support correspondence, Oktul is the controller. Oktul’s privacy policy governs that processing.

2.4 Contact details:

Processor: Oktul OÜ, registry code 17589681, Seebi tn 1-703, 11316 Tallinn, Harjumaa, Estonia
Data protection requests and legal notices: legal@oktul.com
Support and vulnerability reports: the Oktul Help Center (opens in a new tab) or support@oktul.com

3. Data processed

3.1 The Application stores the following in the customer’s Jira site:

Data	Where it is stored	Purpose
The work items each field holds	The value of each Jira custom field	The field’s value
The relationship index: work item keys	The work item property `workItemSelection`, on both work items	Answering which work items a work item selects, and which select it
The configuration of each field context: JQL scope, columns, permission mode, link settings	Forge storage (`storage:app`)	Configuration
A record of each work item link the Application created: the link id and the keys of the two work items	Forge storage (`storage:app`), removed with the link	Deleting the Application’s own links, and only those

3.2 The Application does not store personal data. It reads Atlassian account identifiers and display names to run a search or display a column, uses them within that request, and stores them nowhere. A column showing several people is reduced on the server to the three the card displays. The relationship index holds work item keys only.

3.3 The Application carries out no automated decision-making or profiling within the meaning of Article 22 of the GDPR.

4. Where the data is stored

4.1 All data the Application stores is stored on the Atlassian platform, in the customer’s Jira site. Oktul operates no server or database for the Application and holds no copy of the data.

4.2 The location of the data is determined by Atlassian. Where the customer has configured data residency for Jira, Atlassian stores the Application’s Forge storage in the same location as the customer’s Jira data.

5. Recipients and transfers

5.1 The Application’s Forge manifest declares no permissions.external and no remotes. The Application therefore sends no data outside the Atlassian platform, and uses no analytics, telemetry, error-reporting service or third-party script.

5.2 Atlassian Pty Ltd hosts the Application on the Forge platform on Oktul’s behalf and is Oktul’s only sub-processor for the Application, under the Forge Data Processing Addendum and the standard contractual clauses it incorporates. Atlassian’s own sub-processors are listed at atlassian.com/legal/sub-processors (opens in a new tab).

5.3 The declared permissions are shown on the Marketplace listing under Permissions.

6. Permissions

6.1 The Application requests the following scopes, each for the stated purpose:

Scope	Purpose
`read:jira-work`	Run the JQL scope query and read the fields a card displays
`write:jira-work`	Save a selection, maintain the relationship index and keep a native work item link in step
`read:jira-user`	Display 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 configuration
`read:cmdb-object:jira`	Resolve an Assets object to its label for display as a column. The call is optional and a site without Assets is unaffected
`read:servicedesk-request`	Establish, for a Jira Service Management portal customer, which requests are theirs

6.2 manage:jira-configuration is required to read field context configuration and the field catalogue. Oktul intends to replace it with the granular scopes Atlassian offers.

6.3 read:servicedesk-request is used only for a portal customer, who holds no Jira application access and whom Jira’s search endpoint refuses, and only to establish the requests the customer raised, participates in or has shared with their organisation.

7. Limitations of access control

7.1 In the IGNORE_USER permission mode, the picker searches with the Application’s permissions rather than the viewer’s, so a user can select work items they cannot otherwise browse. The data shown is limited to the columns the administrator configured. RESPECT_USER searches as the viewer and is the recommended mode. Anonymous portal visitors are always restricted.

7.2 JQL search suggestions return work item keys only, because Atlassian requires that request to run with the Application’s permissions and it cannot be limited to the user typing.

7.3 The Automation action writes as the Application, so the change is not recorded against a person and is not limited to what the rule’s owner can see. The field’s JQL scope limits it.

7.4 The JQL scope determines what the picker offers. It does not restrict what a field can hold: a value written through CSV import or the Jira REST API bypasses the picker. Access to data is governed by the customer’s Jira permissions.

8. Retention

8.1 The data is kept for as long as the Application is installed. What Atlassian keeps after the Application is uninstalled is stated in clause 9.

9. Data portability and switching

Work Item Selector keeps all data on the Atlassian platform, in your own Atlassian ecosystem. Nothing is sent outside it, and Oktul holds no copy.

Data	Where it is	How to export it
The work items each field holds	The value of each Jira custom field	Jira's work item export, or the Jira REST API
The relationship index	The work item property workItemSelection, on both work items	The Jira REST API, as work item properties
The configuration of each field context: JQL scope, columns, permission mode, link settings	Forge storage in your site	Shown on each field context's configuration page. Atlassian's export tools do not include Forge storage
A record of each work item link the app created: the link id and the keys of the two work items	Forge storage in your site	Not exported: it exists only so the app deletes its own links, and is removed with each link. Atlassian's export tools do not include Forge storage

After uninstallation. According to Atlassian’s documentation, the fields and their values return if the app is reinstalled within 30 days, and Forge storage is relinked if it is reinstalled within 21 days. Atlassian then deletes the data under its data retention policy.

Oktul charges no fee for switching to another product or for exporting data. Clause 11 of the application licence sets out the terms.

10. Rights of data subjects

10.1 Data subjects have the rights of access, rectification, erasure, restriction of processing, data portability and objection under Articles 15 to 21 of the GDPR. For Customer Data, the controller is the customer, and requests are made to the customer, whose administrators can access, rectify and erase the data with Atlassian’s tools.

10.2 Oktul assists the customer with such requests free of charge, as clause 7.1 of the Addendum provides. Requests concerning data for which Oktul is the controller are sent to legal@oktul.com and answered within one month, extendable by two further months under Article 12(3) of the GDPR.

10.3 A data subject may lodge a complaint with the Estonian Data Protection Inspectorate (Andmekaitse Inspektsioon, Tatari 39, 10134 Tallinn, info@aki.ee) or with the supervisory authority of their habitual residence, place of work or place of the alleged infringement.

11. Security

11.1 According to Atlassian’s documentation, Forge provides tenant isolation and encryption in transit and at rest. Oktul operates no infrastructure in the data path. Oktul’s own measures are set out in clause 5 of the Addendum.

11.2 Oktul holds no audited security certification. The Application is listed in the Cloud Security Alliance STAR Registry at Level 1, a self-assessment of 138 CAIQ Lite questions, which is published in full on the security assessment page. A self-assessment is not an independent audit.

12. Vulnerability reports and security incidents

12.1 A vulnerability is reported through the Oktul Help Center or to support@oktul.com, where it receives a reference. Oktul responds within 24 hours, Monday to Friday, and credits the reporter by name unless asked not to. Oktul does not pay bounties. Research in good faith is covered by clause 8.5 of the application licence. Security testing of a Forge application is testing of the Atlassian platform and must comply with Atlassian’s policies.

12.2 Oktul remediates vulnerabilities within the following periods, measured by CVSS score. The periods under Atlassian’s Security Bug Fix Policy (opens in a new tab) for cloud apps also apply, and the shorter period governs.

Severity	Oktul	Atlassian’s requirement
Critical, CVSS 9.0 or higher	7 calendar days	10 days
High, CVSS 7.0 to 8.9	14 calendar days	4 weeks
Medium, CVSS 4.0 to 6.9	28 calendar days	12 weeks
Low, CVSS below 4.0	56 calendar days	25 weeks

12.3 Oktul notifies the customer of a personal data breach affecting Customer Data without undue delay and in any event within 24 hours, as clause 7.3 of the Addendum provides.

13. Changes to this notice

13.1 The version and effective date at the top of this page identify the version in force. A change is recorded in the release notes. Oktul notifies the technical contacts of installations and Atlassian of a material change.

13.2 Version history. 1.2, effective 28.09.2026: restated in numbered clauses. 1.1, effective 28.09.2026: Atlassian named as sub-processor; retention after uninstallation corrected. 1.0, effective 09.09.2026.