Our applications run inside your Atlassian instance.
Every Oktul application is built on Atlassian Forge. Atlassian operates the runtime, stores the data and enforces your permissions, so there is no Oktul-operated server in the path between your users and their work. What follows is the mechanism, and where to check each part of it yourself.
What Forge is, and why every Oktul application is built on it.
Forge is Atlassian's own application runtime. We build on nothing else, which is what makes the answers below the same for every application we ship rather than a per-product negotiation. They are Atlassian's guarantees rather than ours, and Atlassian's own documentation states every one of them.
- 1The code runs in Atlassian's runtime, on Atlassian's compute
Forge functions execute in Atlassian's own environment, isolated per application, under the scopes the application declares at install. There is no API token, service account or connection string of yours in our custody at any point, no hosting arrangement of ours for you to assess, and no Oktul outage that can affect your apps.
- 2Application data sits in Atlassian storage, and follows your instance
Where an application stores something of its own, it goes in Forge hosted storage, which Atlassian encrypts at rest and scopes to your installation. Data that belongs to a work item stays on the work item. If you move your instance to another residency location, both move with it.
- 3What an application may reach is a list in a file, enforced by a proxy
A Forge app can only reach hosts named in its manifest. Every outbound request passes through an Atlassian proxy that enforces that list at runtime rather than trusting the application to behave. The manifest ships with the application, so you can read the list before you install it, and adding to it forces a fresh approval from your admin.
- 4Runs on Atlassian is Atlassian's verdict, not our claim
Atlassian applies that badge automatically to applications whose manifest shows no egress, Atlassian-hosted storage and matching data residency. We cannot award it to ourselves and cannot opt in. It is granted per application rather than per company.
What reaches us, and the switch that stops it.
This is the one place where something of yours does reach Oktul, so it gets a section rather than a footnote.
When you install a Forge app, Atlassian turns on log sharing automatically and the developer gets access to that application's logs for your site. That is the platform's default rather than a setting we chose, and it applies to every Forge app in your instance, ours included.
We write errors, and nothing else. No work item content, no user records, no measurement of how your team works. Atlassian publishes logging guidelines (opens in a new tab) that tell developers not to log names, email addresses, usernames or user-generated content, and ours follow them.
You do not have to take that on trust. Download the logs from your own admin console, read exactly what we have been receiving, and then decide whether to keep sharing them.
- Go to admin.atlassian.com and select your organisation.
- Select Apps, then Sites, then the site you are administering.
- Select Connected apps, then the application.
- In the Details tab, turn off Logs access.
The same page downloads the logs before you decide, and your log sharing history is in the audit log. Turning it off costs us the ability to diagnose a fault from our side: we will ask you for the log file instead, which is slower. We would rather say that here than discover it with you during an incident.
What we commit to, by severity.
An initial response within 24 hours on every request, from the people who wrote the code. The time to a solution depends on what is wrong, so it is written down per severity rather than promised as one number that would be wrong for most of them.
The clock runs on a request raised in the Help Center, because that is the only channel where it is measured. Email to support@oktul.com opens a request in the same service desk and carries the same targets. An email to any other address reaches a person rather than a queue, and nothing measures it.
Two limits, stated next to the table rather than discovered later. A security severity is the vulnerability's CVSS score rather than our opinion of it, which is why the scores are printed here; for a technical issue we assign the severity and will explain the assignment if you disagree. And this table covers our response, not the platform's availability: Forge is Atlassian's, our applications have no server of ours in the path, and an uptime figure from us would be a promise about somebody else's infrastructure. Atlassian publishes its own status and targets, which is where availability is answered.
Within 24 hours, Monday to Friday. A request raised outside the working week starts its clock at the beginning of the next one. This applies to every severity below, including the ones that carry no resolution target.
Monday to Friday, 09:00 to 17:00, Europe/Tallinn. Resolution targets are in calendar days rather than working days, so a weekend counts against them and the figure means what it says.
The documents, and where to check them.
Every claim on this page is either Atlassian's, and checkable in their documentation, or ours, and written down in one of these.
The company assessment, published rather than described
Oktul is listed in the Cloud Security Alliance STAR Registry at Level 1. That is a self-assessment, not an audit: we completed the CAIQ Lite questionnaire, all 138 questions across the 17 Cloud Controls Matrix domains, and published it for anyone to read. This entry covers the company and carries no application detail. Where an application has been assessed in its own right, that listing is on its own page.
Read the company assessment on the STAR Registry (opens in a new tab)We have had no security breach or incident to date. If one occurs, we tell Atlassian within one hour and, where personal data is affected, the Estonian Data Protection Inspectorate within the 72 hours the GDPR allows.
Raise it in the Help Center (opens in a new tab), or send it 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, and a person who wrote the code reads it. The portal is the better of the two: the routine questions a disclosure starts with, which version, which scope, whether it is already known, are answered there rather than over a week of replies.
Answered at company level, in full.
Each answer stands on its own if it is pasted into a form, which is where most of these end up.