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

The Article 28 terms for that processing are the
**[data processing addendum](/legal/dpa/)**, which is published rather than sent on
request and is incorporated into the [application licence](/legal/app-terms/). 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](/legal/privacy/) 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.

<Aside type="note" title="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](/trust/#platform).
</Aside>

## 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](/legal/dpa/) 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](https://www.aki.ee/en), 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](../caiq/) 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](https://oktul.atlassian.net/servicedesk/customer/portals), or to
[support@oktul.com](mailto: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](/legal/app-terms/).

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](/trust/#sla), 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](https://developer.atlassian.com/platform/marketplace/security-bugfix-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](/legal/dpa/) 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](../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.

## Related

- [Security assessment](../caiq/) — this application's CAIQ Lite answers, in full
- [Data processing addendum](/legal/dpa/) — the Article 28 terms for the processing above
- [Application licence](/legal/app-terms/) — the contract for the software
- [Oktul's website privacy policy](/legal/privacy/) — the company and oktul.com
- [How we handle data](/trust/)
- [Install the app](../install/)

---

A problem or a question? Write to [support@oktul.com](mailto:support@oktul.com) or open a request in the [Help Center](https://oktul.atlassian.net/servicedesk/customer/portals). Both reach the same service desk, so either way the request gets a reference and an SLA measuring the response.