Data Processing Addendum

Last updated 30 July 2026

This addendum applies where Eriksen Labs processes personal data on behalf of a customer through one of our Atlassian Marketplace apps. It forms part of our terms.

We adopt the Bonterms Standard Agreement Data Protection Addendum v2.0, a published standard agreement, on the terms set out below. We use a standard for the same reason we use one for our end user agreement: it is a recognised document that most legal teams have already reviewed, so adopting our apps does not require reading a bespoke contract first.

This page serves as the cover page to that addendum: it records the roles, the processing, the sub-processors, the location of the data, and how breaches, audits and deletion are handled. Where this page and the standard addendum differ, the standard addendum governs, except where this page is more specific about what our apps actually do.

The customer is the data controller. They decide to install an app, decide what to use it for, and hold the resulting data in their own Atlassian instance.

Eriksen Labs is the data processor in respect of personal data that our app code stores or acts upon. We note plainly that we hold no copy of it and have no technical means to read it: it resides in Forge storage inside the customer's own Atlassian instance, and we operate no servers that receive it.

Atlassian is a sub-processor, and separately the customer's own processor under the customer's agreement with Atlassian.

Subject matter and purpose. Recurring Requests for Jira Service Management stores the details of a service request a customer chooses to repeat, so that the same request can be raised again later, either on a schedule or from a saved template.

Nature of processing. Storage, retrieval and re-submission. No profiling, no analytics, no automated decision-making, and no combination with data from any other source.

Categories of data subject.

• Portal customers of the controller who create a recurring schedule or a saved template
• Any individual named or described within the content of the request being repeated — for example, colleagues listed in an access review

Types of personal data.

• The Atlassian account ID of the person who created the schedule or template, which is required to raise the repeated request as that person rather than as the app
• Whatever personal data the controller's users have entered into the request being repeated, including its field values and the answers of any attached form. In practice this commonly includes names, job titles, telephone numbers and email addresses

We do not require, request or infer any special category data. If a controller's users enter such data into a request, it will be stored with the rest of that request's content.

Duration. Until the customer cancels the schedule or deletes the template, until an administrator stops the schedule, or until the app is uninstalled, whichever is first.

Atlassian Pty Ltd is our only sub-processor for app data. It provides the Forge platform on which our apps run and the storage in which app data is held, within the customer's own Atlassian instance.

We engage no other sub-processor for app data. Cloudflare hosts this website and Zoho hosts our email; neither receives app data, and neither is capable of doing so. Both are described in our privacy policy.

If we ever engage a further sub-processor for app data, we will announce it on this page and in the app's Marketplace release notes before it takes effect, so that a controller has the opportunity to object.

App data is held in Forge hosted storage and is located wherever the customer's own Atlassian product is pinned. If an administrator migrates their product to a different location, the app's data migrates with it.

Eriksen Labs performs no international transfer of app data, because we never receive it. Any transfer within Atlassian's infrastructure is governed by the customer's own agreement with Atlassian.

Our security measures are described in full in our security policy. The measures most relevant to processing are structural rather than procedural:

• We operate no servers, hold no infrastructure, and have no ability to read app data
• Our apps declare no external egress. App data is not transmitted outside Atlassian
• Requests are read and created using the acting user's own permissions, so an app cannot reach data that person could not
• Application logs contain identifiers, counts and error messages only, never account IDs, field values or form answers
• Source is scanned for vulnerabilities and for vulnerable dependencies, with results reviewed

We will notify affected controllers without undue delay after becoming aware of a personal data breach affecting their data, and will provide the information available to us so that the controller can meet their own notification obligations. Our acknowledgement and triage targets, and the notification templates we use, are set out in our security policy.

Report a suspected breach or vulnerability to [email protected].

Data subject requests. Because we cannot access app data, a controller can satisfy most requests directly and faster than we could: a customer may delete their own schedules and templates from the portal, an administrator may stop any schedule, and uninstalling the app removes all of its stored data. Where that is not sufficient we will assist, and will explain precisely what the app stores and where.

Erasure. In addition, our apps report the account IDs they hold to Atlassian each week and erase everything associated with an account once Atlassian reports that account closed.

Audit. We will respond to reasonable written requests for information about our processing, and will provide the results of our security scanning on request. We do not host on-site audits, because there is no site: the infrastructure is Atlassian's, and their certifications and audit reports cover it.

Return and deletion. Uninstalling an app removes its stored data. We retain no copy, so there is nothing for us to return or separately delete.

Eriksen ENK, trading as Eriksen Labs, organisation number 937 027 834, Norway. [email protected] for data protection enquiries, or [email protected] for security matters.

Privacy policy · Security policy · Terms