Data Protection Addendum

Last updated 12 October 2026

This addendum is the Bonterms Data Protection Addendum (Version 2.0, Attachment Version), © 2026 Bonterms, Inc., used under CC BY 4.0 and completed by the DPA Details below. Sientus Solutions' Provider-Specific Terms identify it as the DPA for Section 3.3 of the Bonterms Standard End User Agreement, and so incorporate it into the Main Agreement between Customer and Sientus Solutions.

Key Terms

Processing Details

Customer (data exporter)

Provider (data importer)

Details of processing

The details of processing for each Product are in its schedule below; a Product added to the Provider-Specific Terms gets its own schedule. For every Product, the Competent EU Supervisory Authority for Provider is Datatilsynet, the Danish Data Protection Agency, Carl Jacobsens Vej 35, 2500 Valby, Denmark. Where the EU SCCs apply, the competent supervisory authority is the one determined under their Clause 13. Provider's transfers to Atlassian outside the EEA are made under the EU SCCs in the Forge Data Processing Addendum.

Schedule A: Intake Standards for Jira Service Management

Categories of data subjects

• Requesters: people who write a request in the Intake details field on the customer portal. They may be Customer's customers, its employees or other people it serves.
• Agents: people who create a request in the agent view, when the check runs there.
• Customer's project admins who save or enable a version of an intake standard.
• People whom a requester names or describes in a request.

The Intake details field tells requesters, above the box, that AI checks their text. It does not tell them that the run log keeps it. Customer gives requesters the notices Section 3.3 (Compliance with Laws) of this DPA requires, for example in its privacy notice or the request form's help text.

Categories of Customer Personal Data

• User generated content: the requester's text as written in the Intake details field, with any personal data the requester chooses to include, kept on the work item and, up to 10,000 characters, in the run log; and the model's verdict on each check, with an evidence quote from the text or a hint.
• Unique identifiers: the requester's Atlassian account id, when the portal identifies the requester; the account ids of the project admins who saved or enabled a version; a hash of the text; the request key once the request is created.
• Account information: display names, looked up in Jira when they are shown and never stored.
• Other: the details of each check, namely its outcome, the version and work type, the source (customer portal or agent view), the screen it ran on, the time, the duration, token counts, attempts and any error code.
• Log data: event names, ids of projects, work types, work items and runs, standard versions, outcomes, error codes, timings and token counts, in the Forge developer console. No requester text and no account ids.

Sensitive or special categories of personal data

Not intended. The Product is not designed for special categories of personal data or other Sensitive Data (see Section 7.2 of the Standard Agreement). Requesters can still type anything into the field, so Customer tells them not to include such data, as clause 5.7 of the Provider-Specific Terms sets out. If a requester includes such data, it is processed like any other requester text, under the same Security Measures, and the run log keeps it no longer than any other text.

Frequency of transfer

Continuous: each time a check runs, a request is created or a project admin uses the Intake standards page, while the Product is installed.

Nature of the processing

The processing operations required to provide the Service in accordance with the Main Agreement:

• sending the requester's text, with the checks of the enabled standard and the Product's judging instructions, to Atlassian-hosted AI (Forge LLMs) (the model), which returns a verdict, an evidence quote and a hint for each check; text a project admin pastes on the Evaluate tab is sent the same way;
• storing intake standards and run log rows in Forge hosted storage for Customer's installation, and showing them to Customer's project admins on the Intake standards page;
• when a request is created, writing the Intake details value and the issue property intake-gate to the work item, copying the text into Description when Description is empty, and, when the request is flagged for review, adding the label intake-unverified and an internal note that quotes nothing the requester wrote;
• looking up names in Jira to show them;
• writing log lines to the Forge developer console, which Provider reads while Customer's site admin leaves app-log access enabled, to run and support the Product;
• deleting run log rows when they expire.

Purpose of the processing

To provide the Service and carry out Customer Instructions: to check each request against the intake standard Customer has enabled for its project and work type, show the result to the requester, flag requests for review, and keep a 30-day record of checks for Customer's project admins.

Duration of processing and retention

For the term of the Main Agreement, and then as Section 8 (Data Return or Deletion) of this DPA and clause 5.3 of the Provider-Specific Terms provide. Within that:

• Run log rows: 30 days from when each is written; Forge deletes an expired row within about 48 hours.
• Intake standards, every version: until the Product is uninstalled; Atlassian then keeps them for 28 days and deletes them.
• Text pasted on the Evaluate tab: not stored.
• Three small caches hold no personal data: project and work type ids for 10 minutes, a daily Evaluate counter for 1 day, and a monthly run counter for 62 days.
• Log lines in the Forge developer console: 30 days, as Atlassian keeps them.
• Data written to the work item: held in Customer's Atlassian products under Customer's agreement with Atlassian, for as long as the work item exists. Uninstalling removes the Intake details field and its values, which return if the Product is reinstalled within 30 days.

Transfers to Subprocessors

As described in the Subprocessor List: the Product's code runs on Forge, its data is kept in Forge hosted storage and the requester's text is sent to Forge LLMs for each check. Provider also uses the Subprocessors listed for Support when Customer sends Customer Personal Data in a support request.

Subprocessor List

Atlassian runs every Product and processes Customer Personal Data for the Products under the Forge Data Processing Addendum, part of Atlassian's Forge terms with Provider. That addendum incorporates the EU Standard Contractual Clauses, with provisions for the UK and Switzerland, which are the transfer safeguard for transfers to Atlassian outside the EEA. Atlassian is also certified under the EU-US Data Privacy Framework for its companies in the United States. Atlassian decides where Forge stores and processes Customer Personal Data, under its Forge terms; Provider runs no infrastructure of its own. The Products keep Customer Personal Data only in Forge hosted storage, which Atlassian states is data residency enabled: an app installed on a site pinned to a location is located there too, and moves with the site when an admin moves it. Atlassian lists the supported locations, which include the EU, Germany and Switzerland, on its developer site (developer.atlassian.com/platform/forge/data-residency). Where Customer has not pinned its site, Atlassian chooses the location.

For Support, when Customer sends Customer Personal Data in a support request:

Atlassian uses its own sub-processors for Forge. Its sub-processor list, effective 15 May 2026, names the following for Forge. Where Atlassian's Forge entry gives no function or location, the table shows the one in Atlassian's main entry for that company. Where this table and Atlassian's list differ, Atlassian's list prevails. The same page also names the Atlassian group companies that process personal data when providing technical and operational support.

Security Measures

These are Provider's technical and organisational measures for the Service: the Security Measures for Section 3.2 of the Standard Agreement and Section 5 (Security) of this DPA. Provider implements and maintains the measures for the Products. Where a measure is a feature of Atlassian's Forge platform, Provider builds the Products to use it, and Atlassian provides it as Provider's Subprocessor.

Every Product

• Built to run on Atlassian. Each Product is built to Atlassian's Runs on Atlassian rules: its code runs on Forge and its data is kept in Forge hosted storage for each installation, with no egress, no external model keys and no remote backends.
• Site admin control. A site admin installs each Product and accepts the scopes it asks for; a release that adds a scope waits until a site admin accepts it. The site admin decides whether Provider can see the Product's production log lines (app-log access).

Intake Standards for Jira Service Management

• Scopes. read:jira-work, write:jira-work, read:jira-user, read:servicedesk-request and storage:app, with the llm module for Forge LLMs. The manifest declares no external permissions and no web trigger.
• Access control. Every request the Intake standards page makes is checked with Jira, as the person making it, for Administer Projects on that project, and refused without it or when the check fails. The project comes from the context Forge attaches to each request; a project id sent by the browser is ignored. The field's calls run as the app, read only the standard for the form's own project and work type, write at most one run log row per check and cannot reach the settings functions.
• No access by Provider. The deployed Product gives Provider no way to read a Customer's run log or standards; only Customer's project admins see them, inside Customer's site.
• Minimisation. Run log rows expire after 30 days and hold at most 10,000 characters of text. Names are looked up when shown and never stored, and the caches hold ids only. Text on the Evaluate tab is not stored, and text under the word minimum is not logged. Met-when rules never reach the requester's browser.
• Logs. Log lines carry ids, versions, outcomes, error codes, timings and token counts, never requester text or account ids. Tests plant a marker phrase in the text and fail if it reaches a log line.
• Integrity of results. The requester's text reaches the model as data, wrapped apart from the instructions, with a rule never to follow instructions inside it. The model answers through a fixed tool call and cannot rename a check, and code, not the model, applies the pass rule. When a work item is created, a pass counts only if the stored hash matches the text, the standard belongs to the work item's project and work type, and the run log holds that run as a pass, with the same hash and not claimed by another work item. Any other pass is labelled intake-unverified and noted for reviewers.
• Failing open. A model error or timeout never blocks a requester: the request is sent as Unverified, labelled and noted for reviewers, and so is a check refused because the month's run budget is used up. In an incident, Provider can switch every installation to advisory mode with a deploy, and a project admin can disable a standard without a deploy.

Organisational measures

• People. Only the owner of Sientus Solutions can sign in to the Atlassian developer account and deploy. No employee or contractor processes Customer Personal Data.
• Sign-in. The Atlassian developer account and the contact mailbox both require two-step verification.
• Devices. The computers used to build and deploy have full-disk encryption, an automatic screen lock, and operating system updates applied as they are released.
• Releases. Every release passes the automated tests and the Runs on Atlassian rule check before it is deployed, and a release that asks for a new scope waits for a site admin.
• Incidents. Provider learns of incidents from Atlassian, from security reports and from the app log lines it can see. Security reports go to contact@sientus.com, which Provider reads every business day, and are acknowledged within one business day. Provider notifies Customer of a Security Incident by email to the technical contact the Atlassian Marketplace shares with Provider, within the Specified Notice Period of Additional Term 7.
• Review. Provider reviews these measures once a year and after any Security Incident.

Additional Terms

1. Customer Instructions. For Section 3.1 (Customer Instructions), Customer's documented instructions include its configuration and use of the Products: the intake standards its project admins save, enable and disable, the permissions in its Atlassian site, and its site admin's choices on installation, scopes and app-log access. Other instructions go in writing to Provider's contact for data protection.
2. No access in normal operation. In normal operation Provider has no access to Customer Personal Data in Forge hosted storage. In Intake Standards for Jira Service Management, the deployed Product gives Provider no way to read a Customer's run log or standards, and its log lines carry no requester text and no account ids.
3. Return and deletion. For Section 8 (Data Return or Deletion), Customer accesses and deletes Customer Personal Data as clause 5.3 of the Provider-Specific Terms describes; the Products offer no bulk return of data. Before uninstalling, Customer returns Customer Personal Data to itself by reading or copying it in the Product as clause 5.3(a) describes; data written to its work items stays in its Jira. In Intake Standards for Jira Service Management, a single run log row cannot be deleted before it expires after 30 days, and a version of a standard cannot be deleted while the Product is installed; uninstalling is the only earlier deletion. Apart from what Customer has sent in support requests, Provider holds no copy of Customer Personal Data outside Forge. On request, Provider issues a certificate that states the date Customer uninstalled the Product, the deletion rule Atlassian applies to Forge hosted storage, and that, apart from support requests, Provider holds no copy.
4. Audit Reports. Provider holds no third-party audit report or certification of its own. For Section 9 (Audits), the Audit Reports are: (a) Atlassian's SOC 2 reports and ISO 27001 certificate for the Atlassian Platform, which Atlassian states includes Forge, obtained from Atlassian's Compliance Resource Center and Trust Portal (SOC reports under Atlassian's click-through non-disclosure terms); and (b) Provider's written answers to Customer's reasonable security questionnaire about how the Products process Customer Personal Data, given within 30 days, once a year or after a Security Incident. Section 9.3 (Customer Audit) applies where these are not enough.
5. Subprocessor notices. The Subprocessor Notice Method is email to the technical contact that the Atlassian Marketplace shares with Provider for Customer's licence, together with a notice on this page. Section 4.3 (Notice of New Subprocessors) applies to Provider's own Subprocessors. When Atlassian announces a change to its sub-processors for Forge, Provider passes the notice on by the Subprocessor Notice Method within 10 business days of receiving it, and Section 4.4 (Objection to New Subprocessors) applies to it.
6. Data Subject requests. For Section 7 (Data Subject Requests), Customer finds a requester's data in Intake Standards for Jira Service Management on the work item and, for the last 30 days, on the Run log tab, which shows the text and verdicts of each run. The Products give no way to erase a single run log row before it expires or a single version of an intake standard. Provider cannot read or retrieve this data for Customer. Where Customer cannot meet a request through a Product, Provider's assistance under Section 7.1 (Assisting Customer) is to explain what the Product holds about the Data Subject, where it is held and when it will be deleted.
7. Specified Notice Period. For Section 5.2, the Specified Notice Period is 72 hours.