Privacy policy

Last updated 12 October 2026

This policy explains how Sientus Solutions handles personal data in its apps for the Atlassian Marketplace, in support and on this website. Our apps run on Atlassian's Forge platform, and the data they handle stays with Atlassian and the companies Atlassian uses as its own sub-processors. For data in a customer's Atlassian site, the customer decides how it is used and we act on its instructions. We decide how data is used only for the licence data Atlassian sends us, support requests, business correspondence and visits to this website. What each app handles is set out in a schedule at the end.

Who we are

Sientus Solutions is a software product company registered in Denmark as a sole proprietorship (enkeltmandsvirksomhed). It makes the apps this policy covers. "We" and "us" in this policy mean Sientus Solutions.

Address: Nørre Alle 22, 2600 Glostrup, Denmark
CVR number: 39012308
Privacy and legal contact: contact@sientus.com

We have not appointed a data protection officer, because the law does not require one for what we do. Write to the contact above about anything in this policy.

What this policy covers

This policy is for:

people who install, administer or use one of our apps in their organisation's Atlassian site, and people whose data an app handles there, such as requesters on a customer portal;
the billing and technical contacts Atlassian shares with us when an app is installed or bought;
people who ask us for support;
visitors to this website, docs.sientus.com;
people we correspond with about our business.

It covers our cloud apps for the Atlassian Marketplace that are built on Forge to the Runs on Atlassian rules. Today that is one app, Intake Standards for Jira Service Management, described in Schedule 1. Each new app gets its own schedule.

It does not cover what Atlassian does with personal data for its own purposes, which Atlassian's privacy policy covers, or what a customer does in its own Atlassian site, which the customer's own privacy notice covers.

How our apps are built

Our apps are built on Forge, Atlassian's platform for cloud apps, to the Runs on Atlassian rules:

No egress. An app declares no external permissions and calls nothing outside Atlassian.
No external model keys. Where an app uses AI, it uses Atlassian-hosted AI (Forge LLMs) and nothing else.
No remote backends. An app's code runs on Forge. We run no servers of our own that receive app data.

So the data an app handles stays on Atlassian's platform, run by Atlassian and its own sub-processors: in Forge hosted storage, kept separately for each installation, and in the customer's own Jira. Atlassian runs that platform and handles the data as our sub-processor under the Forge Data Processing Addendum (the Forge DPA).

Each app's schedule says who in a customer's site can see its data, and whether we can see any of it. We can read the log lines an app writes to the Forge developer console only while the customer's site admin leaves app-log access enabled. The schedule says what those lines hold.

Our role and Atlassian's

Data protection law gives each party a role. The controller decides why and how personal data is used. A processor handles it for the controller and on its instructions. A processor's own processor is a sub-processor.

Data	Controller	Who handles it for the controller
Data an app processes in a customer's site and keeps in Forge hosted storage	The customer	Sientus Solutions as processor, with Atlassian as our sub-processor under the Forge DPA
Data an app writes into the customer's Jira, such as a field value or a label	The customer	Sientus Solutions as processor when the app writes it, with Atlassian as our sub-processor under the Forge DPA; once written, Atlassian holds it under the customer's own agreement with Atlassian and the Atlassian DPA
Licence, billing and contact data from Atlassian, support requests, business correspondence and this website	Sientus Solutions	The providers listed under Who receives personal data

If your organisation uses one of our apps

If you are a requester, an agent or an admin in a site where one of our apps is installed, the organisation that runs the site is the controller of what the app handles about you. It chose to install the app and decides how it is set up. Its own privacy notice should tell you about it.

To see, correct or delete that data, ask that organisation first. The app's schedule says who in the organisation can see the data. We act only on the organisation's instructions and help it answer. If you write to us instead, we tell the organisation and ask you to send your request to it, because it decides what happens to the data.

What we receive from Atlassian when you install or buy an app

When a customer installs or buys one of our apps, Atlassian creates a licence and shares with us, under the Atlassian Marketplace Terms of Use:

the customer organisation and its site;
licence and order details: type, edition, user tier, dates and status;
the billing and technical contacts given at the order: name, email address, phone number and postal address.

Payment and refunds go through the Atlassian Marketplace, and we do not receive payment card details. If a contact asks Atlassian to erase their data under the right to be forgotten, their details reach us replaced by the letters "RTBF".

Support requests

Until our support portal opens, you reach us through the contact details on the Sientus Solutions partner page on the Atlassian Marketplace, and we answer by email. The support portal will run on Jira Service Management on Atlassian Cloud.

When you ask for help, we receive your name, email address and organisation, your site address, what you write and anything you attach. You do not have to give us personal data, but we cannot answer you without a way to reach you.

Send only what the problem needs. Leave out your users' personal data, such as requester text, where you can, and never send credentials. The Support page lists what helps us. If a request includes personal data from a customer's site, such as a requester's text, we handle that data for the customer as its processor, under our data protection addendum.

This website

This website is a set of static pages. It sets no cookies, runs no scripts, uses no analytics and has no forms. Its fonts and images come from the site itself, so loading a page sends no request to anyone but our host.

Microsoft hosts the site on Azure Static Web Apps. To deliver the pages and protect the service, Microsoft processes connection data: your IP address, the time, the page you ask for and your browser's user agent. We have not turned on any log or analytics service that would give us these records, so we hold none.

Links to other sites, such as the Atlassian Marketplace, lead to pages under their owners' privacy policies.

Business contacts and correspondence

When we correspond with you about our business, for example as a prospective customer, a partner, a supplier or an adviser, we keep your name, email address, organisation and role, your messages and our replies, in our email and office software.

Why we use personal data and on what legal basis

This section covers the data we control. For data an app handles in a customer's site, we act only on the customer's instructions and use the data only to provide the app, as our agreement with the customer and our data protection addendum set out. The customer decides the legal basis for that processing.

Data	Why we use it	Legal basis under the GDPR
Licence and order details	To know who holds a licence for which site, to provide and support the app under it, and to answer licence questions	The contract, where you are the customer yourself, for example as a sole trader (Article 6(1)(b)); otherwise our legitimate interest in managing our contracts with customers (Article 6(1)(f))
Billing and technical contacts	To tell the customer about the app: service and security notices, and changes to our sub-processors, our terms or this policy	Our legitimate interest in keeping customers informed about the service they use (Article 6(1)(f))
Licence and billing records that are accounting records	To keep the accounting records the law requires	Our legal obligation under the Danish Bookkeeping Act (Article 6(1)(c))
Support requests	To answer and solve them, and to keep a record of what we did	The contract, where you are the customer yourself (Article 6(1)(b)); otherwise our legitimate interest in supporting our customers and their staff (Article 6(1)(f))
Website connection data	To deliver the pages and protect the service	Our legitimate interest in publishing our documentation and keeping the site available and secure (Article 6(1)(f))
Business correspondence	To answer you and run our business	Our legitimate interest in running our business (Article 6(1)(f)); our legal obligation where a message is an accounting record (Article 6(1)(c))
Any of the above, when needed	To establish, exercise or defend legal claims, and to answer public authorities	Our legitimate interest in protecting our rights (Article 6(1)(f)); our legal obligation where the law requires us to disclose data (Article 6(1)(c))

We do not rely on consent for any of this. We do not sell personal data or use it for advertising.

Who receives personal data

Recipient	What it handles	Role	Transfer safeguard
Atlassian, through Forge: the app runtime, hosted storage, Forge LLMs and the developer console	Data our apps handle in customers' sites, and app log lines	Our sub-processor under the Forge DPA	EU Standard Contractual Clauses in the Forge DPA, with provisions for the UK and Switzerland; for Atlassian's companies in the United States, also the EU-US Data Privacy Framework
Atlassian, through Jira Service Management, once our support portal opens	Support requests	Our processor under the Atlassian DPA	EU Standard Contractual Clauses in the Atlassian DPA; for Atlassian's companies in the United States, also the EU-US Data Privacy Framework (Atlassian DPA, Schedule 2)
Microsoft, through Azure Static Web Apps	Website connection data	Our processor under the Microsoft Products and Services Data Protection Addendum	EU Standard Contractual Clauses in Microsoft's Data Protection Addendum; for the United States, also the EU-US Data Privacy Framework (Microsoft Products and Services Data Protection Addendum)
Microsoft, through Microsoft 365	Email, including support by email and business correspondence, and the records we keep in our office software	Our processor	Microsoft 365, in the European Union under Microsoft's EU Data Boundary; the EU Standard Contractual Clauses in Microsoft's Data Protection Addendum for the limited transfers Microsoft documents
Public authorities and courts; professional advisers bound by confidentiality, such as an accountant or a lawyer	What a legal duty or a legal claim requires	Controllers in their own right	–

Atlassian is our only sub-processor for the data our apps handle in customers' sites, except what a customer sends us in a support request, which our support providers also handle. Atlassian lists its own sub-processors, including those for Forge, at atlassian.com/legal/sub-processors. We give customers at least 30 days' notice before a new sub-processor of ours handles app data, by email to the technical contact Atlassian shares with us and by a notice on our data protection addendum page, and a customer may object, as our data protection addendum sets out. When Atlassian announces a change to its own sub-processors for Forge, we pass it on the same way within 10 business days.

Transfers outside the EEA

Where a recipient processes personal data outside the European Economic Area (EEA), for example in the United States, the transfer relies on:

Atlassian: the EU Standard Contractual Clauses incorporated in the Forge DPA, with provisions for the UK and Switzerland. Atlassian is also certified under the EU-US Data Privacy Framework, for which the European Commission has adopted an adequacy decision; that certification covers transfers to Atlassian's companies in the United States. The Forge DPA is published on Atlassian's developer site.
Microsoft: the EU Standard Contractual Clauses in Microsoft's Data Protection Addendum, and its certification under the EU-US Data Privacy Framework for the United States. Pages may be served from Microsoft locations around the world, close to the visitor. Microsoft processes this data as our processor under its Products and Services Data Protection Addendum, which incorporates the EU Standard Contractual Clauses for transfers out of the EU, the EEA, the UK and Switzerland.
Microsoft 365, our email and office software: our tenant has a Danish sign-up location and is in scope for Microsoft's EU Data Boundary, so email and office data are stored and processed in the European Union, with the limited transfers Microsoft documents covered by the EU Standard Contractual Clauses in its Data Protection Addendum.

You can ask us for a copy of the safeguard that applies to your data.

How long we keep personal data

Data	How long
Licence records and the billing and technical contacts on them	While the customer relationship lasts, then up to 12 months
Accounting records, such as records of the sales and payments made through the Atlassian Marketplace	Five years from the end of the financial year they belong to, as the Danish Bookkeeping Act requires
Support requests	Up to one year after the request is closed
Business correspondence that is not an accounting record	Up to one year after the last contact
Website connection data	We hold none; Microsoft processes it to deliver and protect the service
Data our apps handle in a customer's site	As the app's schedule sets out; what an app writes into the customer's Jira stays for as long as the customer keeps it

When a period ends, we delete the data.

AI in our apps

An app that uses AI sends data only to Atlassian-hosted AI (Forge LLMs), as set out under How our apps are built. The app's schedule says what it sends and what comes back.

Atlassian handles each request as our sub-processor, under its Forge terms and the Forge DPA.
Atlassian runs the same moderation checks on these requests as on its own AI and Rovo features, and blocks high-risk messages.
Atlassian tells administrators, on the Marketplace listing and during installation, when an app uses Forge LLMs.
We do not use your data to train or fine-tune any AI model.

For our own purposes, we make no decisions about anyone by automated means alone. Where an app judges something automatically for a customer, its schedule explains how the judgement is made and what effect it has.

Security

Our apps keep data on Atlassian's platform and call nothing outside it. For Intake Standards, the Security page explains who can see and change what, how requester text is handled and why it never reaches a log line. The technical and organisational measures we commit to are in our data protection addendum.

If a personal data breach affects data an app handles for a customer, we tell the customer without undue delay and no later than 72 hours after we become aware of it, as the addendum sets out.

Your rights

For the personal data we control, you have the right to:

access it and get a copy;
have it corrected if it is wrong or incomplete;
have it erased, for example when we no longer need it;
restrict our use of it, for example while we check that it is correct;
object to our use of it where we rely on legitimate interests; we then stop, unless we have compelling grounds or need it for a legal claim;
receive it in a portable format, where we use it under a contract and by automated means.

Some rights have limits. For example, we cannot erase accounting records before the period the Danish Bookkeeping Act sets has passed.

To use a right, write to contact@sientus.com. We answer within one month. If a request is complex, we may take up to two more months and tell you why within the first month. We do not charge, and we may ask you to confirm who you are before we act.

For data an app handles in a customer's site, ask the organisation that runs the site first, as described under If your organisation uses one of our apps.

You can complain to Datatilsynet, the Danish Data Protection Agency, Carl Jacobsens Vej 35, 2500 Valby, Denmark, www.datatilsynet.dk. You can also complain to the supervisory authority where you live or work, or where you think the law was broken.

Children

Our apps and this website are made for organisations and are not aimed at children. We do not knowingly collect children's personal data for our own purposes. A customer decides who may use its site; if children use a site where one of our apps runs, the customer is responsible for that data as controller.

Changes to this policy

We update this policy when our apps, our providers or the law change, and we add a schedule when we add an app. The date at the top shows when this version took effect. If a change affects how we handle personal data we already hold, we tell our customers' billing and technical contacts by email before it takes effect.

Schedule 1: Intake Standards for Jira Service Management

Intake Standards replaces the free-text Description on a Jira Service Management request form with the Intake details field. When the requester leaves the box or presses Check or Send, Atlassian-hosted AI (Forge LLMs) judges the text against the intake standard the project admins have enabled for that work type, and the field shows which checks are met and which are not.

For all the data below, the customer is the controller and we act for it. We use the data only to provide the app: to run the check, show the result on the request form and the work item, and keep the run log for project admins. What the app keeps in Forge hosted storage is handled by Atlassian as our sub-processor under the Forge DPA. The app writes to the work item for the customer; what it writes is then held in the customer's Jira under the customer's own agreement with Atlassian. Your data gives the full detail.

Whose data

Requesters on the customer portal: what they type into the Intake details field, and their Atlassian account id.
Agents who create a request in the agent view: the same, when the check runs there.
Project admins: the account ids of whoever saved or enabled each version of a standard.
Anyone a requester mentions in the text.

The text comes from the person who types it, and account ids come from Atlassian with each request. Names are looked up in Jira when they are shown and never stored.

What the app keeps

Run log, in Forge hosted storage. The app writes one row each time the model checks a text against an enabled version, on the customer portal or in the agent view. Checks that end Unverified because the model failed twice, and checks on text the requester never sent, are logged too. A row holds:

the text as checked, up to 10,000 characters, and a hash of it;
the Atlassian account id of the person who typed it, or a mark that the portal did not identify them;
the outcome, and each check's verdict with its evidence quote or hint;
the version of the standard, the work type, the source (customer portal or agent view) and the screen the check ran on;
when the check ran, how long it took, the tokens used, the number of attempts and any error code;
the request key, once the request is created.

Text under the word minimum is not logged, because it fails on the count without a model call. Nor are checks on the Evaluate tab, or requests for a work type with no enabled standard.

Intake standards, in Forge hosted storage. Every version of every standard: its checks (label, met-when rule and hint), the word minimum, the box wording, any skip rule and the template it started from, with the account ids of who saved and enabled it, and when. The app never deletes a version.

On the work item, in the customer's Jira, when the request is created:

the Intake details value: the text, its status, each check's verdict with its quote or hint, the version of the standard and when the check ran;
a copy of the text in Description, when Description was empty;
the label intake-unverified and an internal note when the value is not a verified pass, except on a work type with no enabled standard; the note quotes nothing the requester wrote;
the issue property intake-gate: the status, whether the value was verified and flagged, the standard, the run id and the text's hash.

Small caches, in Forge hosted storage: a request-type lookup that holds project and work type ids only, a daily counter for the Evaluate tab, and a monthly counter of runs.

Developer logs, in the Forge developer console: event names; ids of projects, work types, work items and runs; standard versions, outcomes, error codes, timings and token counts. Never requester text and never account ids: tests plant a marker phrase in the text and fail if it reaches a log line.

What the model receives

When a check runs, the app sends Forge LLMs the requester's text, the checks of the standard with their labels and met-when rules, and the app's own judging instructions. The model returns a verdict, an evidence quote and a hint for each check, which the app keeps in the run log row and the field value. The model works on text only: attachments and screenshots are not sent, and nothing behind a link is opened. Text pasted on the Evaluate tab goes to the model the same way and is not stored.

Who can see it

The run log: only people with Administer Projects on the project, on the Run log tab. The app checks that permission on its server, as the person asking, for every request the tab makes.
Standards: project admins, on the Intake standards page under Project settings. Requesters see the labels, hints and box wording on the request form; the met-when rules never reach their browser.
The work item: anyone Jira lets see it, as with any other field, label or comment. Requesters do not see internal notes. On the customer portal, the requester and anyone the request is shared with can see the Intake details field: its status, the text and each check's verdict.
Sientus Solutions: the app gives us no way to read a customer's run log or standards. We see the developer log lines above only while the customer's site admin leaves app-log access enabled.

How the check affects requesters

The check is automated. The model judges each check, and code applies the pass rule: a text passes only when every check is met. On the customer portal, while a check is not met, the field holds back its required value, so the portal's own required-field message stops the request from being sent. The requester can add to the text and try again. If the standard has a skip rule, the requester can send the request anyway, at once or after a set number of failed checks; it then arrives as Incomplete, labelled intake-unverified, with an internal note that names the bypass. In the agent view the check never blocks. If the model fails or times out, the request goes through as Unverified and is flagged for review. The customer writes the checks and decides what happens to every request that is sent. A request the check holds back is not sent, and no one at the customer sees it. Where a blocked request could significantly affect a requester, the customer should set a skip rule or offer another way to reach it, and assess whether Article 22 of the GDPR applies. We help with that assessment under our data protection addendum.

The field tells requesters, above the box, that AI checks their text. It does not tell them that the run log keeps it for 30 days; the customer's own privacy notice, or the request form's help text, should.

In an incident we can switch every installation to advisory mode, in which the checklist stays and nothing blocks.

Special categories of data

The app is not designed for special categories of personal data, such as health information, or national identification numbers such as a Danish CPR number. Requesters can still type anything into the box, so we advise customers to tell requesters not to include such data.

Permissions

The app asks Jira for read:jira-work, write:jira-work, read:jira-user, read:servicedesk-request and storage:app, and declares the llm module for Forge LLMs. The Security page explains why it needs each.

How long it is kept

Data	Where	Who sees it	Kept for
Intake standards, every version	Hosted storage, the customer's installation	Project admins; requesters see labels, hints and box wording	Until the app is uninstalled, then 28 days
Run log rows	Hosted storage, the customer's installation	Project admins of that project	30 days, then deleted within about 48 hours
Intake details value	The work item	People who can see the work item, including the requester on the portal	As long as the work item; removed on uninstall, back if the app is reinstalled within 30 days
Description copy	The work item	People who can see the work item	As long as the work item
Label, internal note, `intake-gate`	The work item	People who can see the work item; requesters do not see internal notes	As long as the work item
Request-type lookup, project and work type ids only	Hosted storage, the customer's installation	The app only	10 minutes
Evaluate counter	Hosted storage, the customer's installation	The app only	1 day
Monthly run counter	Hosted storage, the customer's installation	The app only; project admins see the count	62 days
Text pasted on the Evaluate tab	Sent to the model, not stored	The project admin who pasted it	Not kept
Developer log lines	Forge developer console	Sientus Solutions, while the site admin leaves app-log access enabled	30 days, as Atlassian keeps them in the developer console

If the customer uninstalls

The Intake details field and its values are removed. They return if the app is reinstalled within 30 days.
Atlassian keeps the app's hosted storage, every standard and run log row, for 28 days and does not restore it automatically on reinstall. A recovery request must reach Atlassian within 21 days.
What the app wrote elsewhere on the work item, the Description copy, the label, the internal note and the issue property, stays in the customer's Jira under the customer's control.

Requests from the people whose data it is

Project admins can read the run log on the Run log tab, which shows who typed each text, to answer an access request. The app cannot delete or change a single row; every row is hidden after 30 days and deleted within about 48 hours after that. Text on the work item is corrected or deleted in Jira, like any other field. The account ids in a standard's version history stay until the app is uninstalled, as the customer's record of who changed its configuration. If a customer needs more for a request, it can ask us and we help as our data protection addendum sets out.