Privacy and data handling
What Oktul Work Item Macro for Confluence stores, where it stores it, and what leaves your Atlassian ecosystem. Nothing does.
Version 1.1, effective 03.11.2026.
1. Scope
1.1 This notice describes the processing of personal data by Oktul Work Item Macro for Confluence (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 Confluence Cloud site:
| Data | Where it is stored | Purpose |
|---|---|---|
| The configuration of each macro: JQL query, results per page, columns with their headings and display options, and the inline editing settings | The macro’s parameters, in the Confluence page that holds it, stored by Confluence | Configuration |
3.2 The Application has no Forge storage and keeps nothing else. It does not cache.
3.3 When a page is viewed, the Application reads work items, Assets objects and Jira fields from the customer’s site, as the viewing user, and displays them in that user’s browser. When a page is exported, the Application does the same as the user the export is made for, in its export function on Atlassian Forge, and returns the table to Confluence. That data may include personal data held in work items, such as account identifiers, display names and anything written in a field. It is used within that request only and stored nowhere by the Application. A JQL query may name a person, and is stored as written, in the page.
3.4 In the Advanced edition, a change made in the table is sent to Jira as the user making it, and Jira stores it as it would a change made in Jira.
3.5 When a request fails during an export, the export function writes the failure to the Forge logs, which Atlassian shares with Oktul unless the customer’s administrator turns log sharing off. The entry can include Assets object identifiers, the text of Jira’s error message, which can quote the JQL query, and, for an Assets request that was refused, the body of the refusal. It does not include the field values of work items. On screen, the same messages go to the viewing user’s browser console and do not reach Oktul.
3.6 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 Confluence Cloud 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. The macro configuration is part of the Confluence page, so it is stored wherever Atlassian stores that page, including under any data residency the customer has configured for Confluence Cloud.
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 | Why it is requested |
|---|---|
read:jira-work |
Run the macro’s JQL query, read the fields a row displays and load what the inline editor offers |
write:jira-work |
Save an inline edit or a status transition as the viewing user, in the Advanced edition |
read:cmdb-object:jira |
Display an Assets object by its label and search objects in the inline editor |
read:cmdb-icon:jira |
Read the names of Assets’ predefined icons, so each object chip displays its icon |
7. Limitations of access control
7.1 In the Advanced edition, the editor for an Oktul Work Item Selector field offers any work item the user can find in Jira’s work item picker. The Application cannot read that field’s JQL scope or permission mode, so the scope does not limit what can be chosen in the table.
7.2 The JQL query is stored in the page as written. A user who can read the page’s content can read the query, whatever that user may see in Jira.
8. Retention
8.1 The macro configuration is part of the page, so Confluence keeps it for as long as it keeps the page and its versions, whether or not the Application is installed. Removing the macro, or deleting the page, removes it as Confluence removes any other page content. What Atlassian keeps after the Application is uninstalled is stated in clause 9.
9. Data portability and switching
Work Item Macro 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 configuration of each macro: JQL query, results per page, columns and inline editing settings | The macro’s parameters, in the Confluence page that holds it | Part of the page body, so Confluence's space export and the Confluence REST API include it |
After uninstallation. The macro configuration stays in the page, as any other page content does. The app has no Forge storage, so nothing else remains.
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.
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’s own measures are set out in clause 5 of the Addendum.
11.2 Every request the Application makes to Jira and Assets runs as a user: on screen, from the viewing user’s browser; in an export, as the user the export is made for. The Application never calls Jira or Assets with its own identity, so it reads and changes only what that user may read and change, and Jira applies its permissions, screens and validation to every change. The Application sends no data outside the Atlassian platform and itself loads no image or script from outside its own code. People are drawn with Atlassian’s own user component, which shows their profile picture from Atlassian.
11.3 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 in the registry and linked from the security assessment page. A self-assessment is not an independent audit.
11.4 Oktul’s own security testing, set out in clause 5.6 of the Addendum, applies to the Application. Its code is scanned before each release and on the 1st of every month; the first scan ran on 01.11.2026. The Application has no web trigger, which is the one kind of entry point Forge opens to anonymous callers. Its dynamic testing is therefore the penetration test, run as signed-in users on Oktul’s test site. Its suite, written on 01.11.2026, holds 73 cases for the 10 entry points in its code, and first ran in full on 03.11.2026. Oktul runs that suite by hand every six months and whenever an entry point is new or changed, and its automated checks run with every scan. Before each release Oktul also reviews the Application’s software bill of materials (SBOM): every package added, upgraded or removed since the last review, and every licence that needs reading. Oktul gives the SBOM to a customer who asks for it.
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.1, effective 03.11.2026: Oktul’s security testing in clause 11.4. 1.0, effective 08.10.2026.