# Privacy and data handling

> What Oktul Regex Field for Jira stores, where it stores it, and what leaves your Atlassian site. Nothing does.
>
> Documentation for Oktul Regex Field for Jira, for Jira Cloud, by Oktul: https://oktul.com/docs/plugins/regex-field/privacy/

**Draft. This notice takes effect when Oktul Regex Field for Jira is published on the Atlassian Marketplace.**

**Version 1.0, effective 10.10.2026.**

## 1. Scope

1.1 This notice describes the processing of personal data by Oktul Regex Field for Jira (the
“Application”). It forms part of the [application licence](https://oktul.com/legal/app-terms/) and is read with
the [data processing addendum](https://oktul.com/legal/dpa/) (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](https://oktul.com/legal/privacy/).

## 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](https://oktul.atlassian.net/servicedesk/customer/portals)
  or support@oktul.com

## 3. Data processed

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

- **The values people enter in the Application's fields**, as Jira custom field values in
  the work items that hold them: a text, or a rich text document together with its plain
  text.
- **The rules an administrator sets for each field context**: the format, the allowed
  characters, the other rules or the regular expression, the placeholder, the error message
  and the prefill template, as the field's own context configuration.

3.2 Where a field context has a prefill template that names the person, the Application reads
that person's name, email address or account id from Jira in their browser, as them, when they
open a create screen or a portal request form. The values are placed in the field and are not
sent to Oktul or stored by the Application. If the person creates the work item, the value
becomes part of it like anything they typed, and they can change or clear it first. An email
address is read only where the person's Atlassian profile shows it.

3.3 Where a prefill template names another field, the Application's UI modification reads that
field's value on Jira's create screens, the work item view, transition screens and portal
request forms, in the person's browser and as them, and places it in the field. A field the
form does not hold is read from the saved work item, and a person the template names from Jira's
user directory, both as the person. On the work item view Jira saves a value as it is placed, so
the Application fills only an empty field there and never writes as the view opens. It reads
only the fields the template names. Nothing it reads is sent to Oktul or stored by the
Application. To know where to run, the Application reads, as itself, where each of its fields is
used: the field's contexts and field configurations, and the portal request types that list it.
These are configuration, not work item data.

3.4 Where a field context has Keep in sync on, a work item created or changed outside a form, by
Automation, a script, the REST API or another app, is read by the Application on Atlassian's
platform: the fields the template names and the field itself. If the value is still the template
filled in, or empty, the Application saves it filled in again, as the account that made the change
or, where that was an app account, as the Application. It writes nothing but its own field.
Nothing it reads is sent to Oktul or stored by the Application.

The Application uses no Forge storage. It keeps no copy of any of this, and logs no value.

3.5 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 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. Where the customer has configured data
residency for Jira Cloud, Atlassian stores the Application’s Forge storage in the same
location as the customer’s Jira Cloud 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](https://www.atlassian.com/legal/sub-processors).

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` | To read the space and work type a prefill names, and a field a template names from the saved work item, as the person, and the site's fields and spaces, to find where each of the Application's fields is used. |
| `read:jira-user` | To read the name and email address of the person creating a work item, as them, when a prefill names them. |
| `manage:jira-configuration` | To read the rules an administrator set for the field when someone opens its editor, so the editor can check the value and format it as they type; to read the field's contexts and field configurations; and to create and update the Application's own UI modifications. Jira requires this scope for those reads. The Application changes no other configuration with it. |
| `manage:jira-project` | Declared with the Application's UI modifications, as Atlassian's documentation for them asks. The Application uses it read-only. |
| `read:servicedesk-request` | To read which portal request types list the field. |
| `write:jira-work` | To place a value filled from other fields in the field on a Jira form, as the person. On the work item view Jira saves it at once, so the Application fills only an empty field there. |

## 7. Retention

7.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 8.

## 8. Data portability and switching

Regex Field keeps all data on the Atlassian platform, in your own site. Nothing is sent outside it, and Oktul holds no copy.

| Data | Where it is | How to export it |
|---|---|---|
| The values entered in the fields: a text, or a rich text document with its plain text | Jira custom field values, in the work items that hold them | Jira's own export (CSV, Excel) and the Jira REST API, as for any custom field |
| The rules set for each field context: the format, the allowed characters, the other rules or the regular expression, the placeholder, the message and the prefill template | The field's context configuration, in Jira | The Jira REST API, to a Jira administrator |

**After uninstallation.** According to Atlassian’s documentation, the fields and their values return if the app is reinstalled within 30 days, and Atlassian then deletes them under its data retention policy. The app has no Forge storage, so it keeps nothing of its own.

Oktul charges no fee for switching to another product or for exporting data. [Clause 11 of the application licence](https://oktul.com/legal/app-terms/#switching) sets out the terms.

## 9. Rights of data subjects

9.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.

9.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.

9.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.

## 10. Security

10.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.

10.2 Work item data is read and written as the person: through Jira's own field save, and from
their browser. The Application acts as itself for two things only: reading the rules saved for
its own fields, which Jira does not show a person who is not an administrator, and the
configuration reads and UI modification writes described in clause 3.3. It never reads or writes
a work item as itself. Jira checks every rule in the field's own validation on every save,
whatever writes the value. The Application sends no data outside the Atlassian platform and
loads no image or script from outside its own code.

10.3 Oktul holds no audited security certification, and the Application is not listed in the
Cloud Security Alliance STAR Registry.

## 11. Vulnerability reports and security incidents

11.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.

11.2 Oktul remediates vulnerabilities within the following periods, measured by CVSS score. The
periods under Atlassian’s [Security Bug Fix Policy](https://developer.atlassian.com/platform/marketplace/security-bugfix-policy/)
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 |

11.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.

## 12. Changes to this notice

12.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](../release-notes/). Oktul notifies the technical
contacts of installations and Atlassian of a material change.