Data Processing Addendum

Last updated 25 September 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.

This addendum covers the Eriksen Labs apps distributed through the Atlassian Marketplace, where an app may process personal data held in your Atlassian tenancy on your behalf.

It does not apply to what it does, and does not need to. That product processes no personal data for you: the scanner runs on your machine, the pull request check runs in your own CI runner, and no content of yours is transmitted to us at any point. We are not a processor for it because there is nothing of yours for us to process. If your procurement requires a signed DPA regardless, write to support@eriksenlabs.com and we will sign one stating exactly that.

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 or, for Issue Templates' Create dialog settings and alert issues, in the customer's own Jira site, 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.

Recurring Requests & Templates for Jira Service Management

Subject matter and purpose. Recurring Requests & Templates 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.

Issue Templates & Create Defaults for Jira

Subject matter and purpose. Issue Templates & Create Defaults for Jira stores issue templates that the controller's administrators write, or save from an existing issue, and fills them into Jira's Create dialog, so that new issues start in the controller's own format.

Nature of processing. Storage and retrieval of templates and their earlier versions. When someone opens Save as template on an issue, the app reads that issue's summary, description, labels, priority, issue type and project with that person's own permissions. Before anything is stored, it removes @mentions, attachments, other apps' content, links to people's profiles and personal spaces, and links that contain an email address from the description, and replaces email addresses written in it. Only a Jira administrator, or an administrator of that project, can then save it. When someone opens Jira's Create dialog, the app fills in the template in that person's own browser; what they type there is compared in the browser, and the app neither stores it nor sends it anywhere. A daily check compares each template with the projects it is for. No profiling, no analytics about people (the only usage kept is a count per template and when it was last used), no automated decision-making, and no combination with data from any other source.

Categories of data subject.

• Any individual named or described within a template's text — for example, a person an administrator names as a triage owner, or someone named in plain words in an issue saved as a template
• People @mentioned, linked or emailed in an issue opened in Save as template, whose details the app reads only in order to remove them
• People filling in Jira's Create dialog in a project with an automatic default, whose entries the app reads in their own browser and does not keep

Types of personal data.

• Whatever personal data the controller's administrators type into a template, or leave in plain words in an issue saved as one, such as a name or a telephone number. A template's name, summary, checklist and labels, and a description typed in the app's own editor, are kept as written
• In passing, and never stored: the account IDs, display names and email addresses in the description of an issue opened in Save as template, which are removed before anything is kept, and what a person writes in the Create dialog, which is read only in their own browser

The app records nothing about the people who use it: it adds no account ID, name or email address of anyone who creates, uses, changes, restores or deletes a template, and usage is kept only as counts and a time. It therefore holds no account IDs to report to Atlassian. We do not require, request or infer any special category data.

Who can see it. Templates are not private to administrators. Anyone who can see a project a template is for can read the template on that project's Templates page and on the Templates page in the Apps menu, and the text of a project's automatic defaults reaches the browser of anyone who opens the Create dialog there.

Where it is held. Templates, their earlier versions, deleted templates kept for restoring, usage counts and the daily check's settings and findings are held in Forge hosted storage. The Create dialog settings, which include a copy of each automatic default's text, are held by Jira itself in the controller's own site, through Jira's UI modifications feature. Alert issues the daily check creates are ordinary issues in the controller's own project. When someone picks a template on a Templates page, its summary and description words are also kept in that browser tab's session storage until the Create dialog closes or the tab is closed, and are ignored after two hours.

How it acts. Reading an issue for Save as template, and checking what the caller may do, use that person's own permissions. The Create dialog settings are written by the app itself, because Jira lets only the app that made them manage them, and only after the app has checked that the person saving is allowed to. The checks and the alert issue are also handled by the app itself, because the daily check runs with nobody signed in; that work reads Jira's configuration (projects, issue types, create screens and priorities), not issue content. Only Jira administrators can change a template shared by several projects, or set up and run the daily check; a project administrator can change the templates that are for their project alone, and check that project's templates.

Duration. A template is kept until an administrator deletes it. Up to 50 of its saved versions, the newest being the template as it is now, are kept with it, so text removed from a template stays in its earlier versions until later saves push them out or the template is deleted. A deleted template, with its versions and usage counts, can be restored for 30 days; after that it is removed for good by the app's next daily check, or when an administrator next opens the app's settings (only the latter while the subscription has lapsed). The daily check keeps the findings of its 20 most recent runs that found a problem. A project's Create dialog settings are rewritten whenever one of its templates is saved, deleted or restored, or an administrator rebuilds them, and are removed at that point if the project no longer has an automatic default.

After the app is uninstalled, Atlassian's platform keeps its Forge hosted storage for 28 days under Atlassian's own rules; we cannot read it at any point. The app does not remove the Create dialog settings it kept in Jira when it is uninstalled; turning off automatic fill on every template, or deleting the templates, removes them beforehand. Alert issues are the controller's own issues and stay until the controller deletes them.

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 held in Forge hosted storage is located wherever the customer's own Atlassian product is pinned, and if an administrator migrates their product to a different location, it migrates with it. Issue Templates also keeps its Create dialog settings in Jira, through Jira's UI modifications feature, and creates its alert issues in the customer's own project; neither is held in Forge storage, so neither is within the app's data residency scope.

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
• Recurring Requests reads and creates requests with the acting user's own permissions, so it cannot reach data that person could not. Issue Templates reads an issue saved as a template with the saving person's permissions; the work it does as the app itself (its Create dialog settings, the checks and the optional alert issue) reads Jira's configuration rather than issue content, and runs only after an administrator has been confirmed, or from the daily check
• 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 security@eriksenlabs.com.

Data subject requests. Because we cannot access app data, a controller can satisfy most requests directly and faster than we could. In Recurring Requests, a customer may delete their own schedules and templates from the portal, and an administrator may stop any schedule. In Issue Templates, a Jira administrator may edit or delete any template, and a project administrator those for their project alone; a template's earlier versions keep its old text until later saves push them out, or until a deleted template is removed after 30 days. Where that is not sufficient we will assist, and will explain precisely what the app stores and where.

Erasure. In addition, Recurring Requests reports the account IDs it holds to Atlassian each week and erases everything associated with an account once Atlassian reports that account closed. Issue Templates holds no account IDs, so it has none to report.

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 ends its use of its stored data. Atlassian's platform keeps an uninstalled app's Forge hosted storage for 28 days under Atlassian's own rules, and Issue Templates' Create dialog settings in Jira are not removed on uninstall, as set out above. 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. support@eriksenlabs.com for data protection enquiries, or security@eriksenlabs.com for security matters.

Privacy policy · Security policy · Terms