Trust center
One page for security reviews, procurement and partners: what each app can reach, what it stores and where, who can read it, and the answers already given on each app's Atlassian Marketplace listing. Everything here can be checked: the permissions on Atlassian's install screen, the Privacy & Security tab of each listing, and the pages linked from each section. Where the apps differ, we say so per app rather than make one claim that flatters the weaker case.
In short
- The apps run on Atlassian Forge, inside your Atlassian site. We operate no servers, and the apps declare no external addresses, so nothing leaves Atlassian: not to us, not to anyone.
- We cannot read what the apps store. There is no mechanism for us to retrieve it, and no support process that involves it.
- Each app asks only for the permissions it needs, or that Atlassian requires as a group for a module it uses. They are listed per app below and shown on the install screen.
- Issue Templates & Create Defaults records nothing about the people who use it: no account IDs, no names, not who made or used a template. Recurring Requests does hold personal data, and says exactly what. Mermaid Diagrams & Gantt stores nothing.
- We hold no SOC 2 or ISO 27001 certificate and have not completed a CAIQ. We say so rather than imply otherwise; the useful question for these apps is what they can reach, which is answered here.
Common to every app
Hosting
Atlassian Forge, in your Atlassian site. We operate no servers and hold no infrastructure of our own for the apps.
Egress
None declared. Forge enforces it: an app without declared external addresses cannot make outbound calls.
Telemetry
None. No analytics, no tracking, no cookies in the apps.
Our access
None. We cannot read app data, and hold no mechanism to retrieve it.
Sub-processors
Atlassian only, as the platform and storage provider. No other sub-processor for app data; see the DPA.
Location
App data in Forge hosted storage is located wherever your own Atlassian product is pinned, and migrates with it. We perform no international transfer, because we never receive it.
After uninstall
Atlassian keeps an app's Forge hosted storage for 28 days after it is uninstalled, then deletes it. We cannot read it at any point.
Contacts
[email protected] for vulnerabilities (also in security.txt); [email protected] for everything else.
Issue Templates & Create Defaults for Jira
The answers below are the ones given on the listing's Privacy & Security tab and in Atlassian's Forge security questionnaire, first on 23 September 2026 and re-checked at each release since. The full list of what the app stores, where and for how long is in the documentation; the privacy policy says the same in its own words.
| Runs on Atlassian | Yes. The badge is on the Marketplace listing: the app runs entirely on Atlassian's platform, with no egress. |
|---|---|
| Permission scopes | Six, all shown on the install screen. Five are the group Atlassian requires in full for apps that work in Jira's Create dialog: read:jira-work, write:jira-work, manage:jira-configuration, read:jira-user and manage:jira-project; the sixth is storage:app. The app makes no use of read:jira-user or manage:jira-project. What each of the others is used for is in the security policy. |
| Who creates work items | Jira does, as the person: a template picked on the Templates page opens Jira's own Create dialog, filled in. The template's child work items and sub-tasks are created through Jira's API with that person's own permissions, or, from a Jira Automation rule, as the rule's user. The only work item the app creates as itself is the optional alert issue of the daily check. It never edits or deletes a work item. |
| Stores data | Yes, in Forge hosted storage, scoped to your site: templates, their last 50 versions, deleted templates for 30 days, usage counts and dates, the daily check's settings and findings, runs of child work items for 30 days, and whether an administrator hid the Get started steps. Two things are kept in Jira itself: a copy of each default template in Jira's Create dialog settings, and alert issues, which are ordinary work items in your project. |
| Personal data | None recorded about the people who use it: no account IDs, names or email addresses, and not who made, changed, used, restored or deleted a template. A template holds whatever an administrator types or copies from a work item; Save as template removes @mentions, attachments, other apps' content, profile and email links and email addresses from a copied description. When a template assigns work to "the person using it", that person's account ID is read from Jira at that moment and not stored. Listing declaration: the app does not store personal data. |
| Data residency | Supported. Forge hosted storage is pinned and migrated by Atlassian with your product; the listing lists Australia, Canada, EU, Germany, India, Japan, Singapore, South Korea, Switzerland, United Kingdom and USA. Out of scope, as declared: the app's Forge logs, text kept in a person's own browser tab while a Create dialog is open, the Create dialog settings Jira keeps, and alert issues in your project. |
| Retention | A template until an administrator deletes it, then 30 days in Recently deleted; the last 50 versions per template; the last 20 daily checks that found something; a run 30 days after it last changed. After uninstall, Atlassian keeps the app's storage for 28 days (declared on the listing as 28 to 29 days), then deletes it. The Create dialog settings are Jira's: the documentation says how to clear them before uninstalling. Alert issues stay, as they are yours. |
| Logs | Forge logs, kept by Atlassian, readable by us to fix problems. They hold error kinds and field IDs from the Create dialog, and short error messages from the app's own steps. No account IDs, no form content, no work item text. Listing declaration: the app does not log End-User Data. |
| In the browser | While a Create dialog opened from the Templates page is open, that tab keeps the picked template's text so the dialog leaves it alone; it is removed when the dialog or tab closes. If someone answers the Templates page's rating ask, their browser keeps that answer. Neither leaves the browser; neither says anything about the person. |
| Egress and remotes | None. No external addresses, no remote hosts, no web triggers, no REST API of its own. Listing declarations: no End-User Data stored, processed or logged outside Atlassian; nothing shared with third parties. |
| GDPR and CCPA | Eriksen Labs acts as a processor, under the DPA; not a controller. CCPA: not applicable. No transfers out of the EEA by us; nothing leaves Atlassian. |
| Certifications, bug bounty | No SOC 2, ISO 27001 or CAIQ. Not enrolled in the Marketplace bug bounty programme; vulnerability reports go to [email protected] and are handled as the security policy says. |
The Forge security questionnaire, answered
Atlassian asks every Forge partner the same questions. These are the answers for this app, each checked against the code.
| User interactions, run as the user | Yes. Pages, the Templates page, the Create dialog and the Automation actions. Reading a work item for Save as template, the caller's permissions, projects, work types and priorities, and creating child work items, all run as the person. The app acts as itself only where Jira requires it (its own Create dialog settings), for the daily check, which has no user, and for the alert issue it files as itself. |
|---|---|
| Permission checks before acting as the app | Yes. Every route into an app-level call first checks the caller against Jira's own permissions: Jira administrator on the admin page, project or Jira administrator on a project's pages. The project a request concerns, and the work item an action is on, come from the platform's context, never from the request body. |
| Forge Remote, web triggers, display conditions | None of the three. |
| Least privilege | Yes. The five Jira scopes are the group Atlassian requires as a whole for the Create dialog module; two of them are unused and declared so. storage:app is the app's own storage. |
| Sensitive data in logs | No. Error kinds, field IDs and short platform error messages only. |
| Input validation | Every input is validated in the app's Forge functions, whatever the browser sends: IDs by pattern, template fields type-checked, trimmed and capped; formatted descriptions pass an allowlist sanitiser before storage, which also removes mentions, attachments and other apps' content; Jira API paths are built with Forge's route tag; template text is rendered as text, never as markup. |
| Dependencies and scans | Before each release: npm audit on the shipped dependencies and a static security scan (ESLint with the security and no-unsanitized plugins). Dependencies are pinned and reviewed before upgrade: Atlassian's Forge packages and React. |
| Credentials and secrets | The app asks for no password, token or key, and holds no secrets. |
| Atlassian's bug fix policy and incident guide | Read and followed; see incident response. Confirmed critical or high severity issues are reported to Atlassian and affected customers within Atlassian's timeframes, before a fix is ready if need be. |
Recurring Requests & Templates for Jira Service Management
This app does hold personal data, and the privacy policy sets out exactly what. In brief:
| Permission scopes | Five, all shown on the install screen: read:servicedesk-request and write:servicedesk-request to read the request being repeated and create the new one, read:jira-work to read the answers of an attached form, storage:app for schedules, templates and settings, and report:personal-data. |
|---|---|
| Acting as a person | The two service desk scopes allow a scheduled request to be created as the customer who asked for it, rather than as the app. That identity always comes from the platform's context at the moment the schedule was created, never from anything a browser can send. |
| Stores data | Yes, in Forge hosted storage scoped to your site: the schedules and templates, the details of the requests being repeated, and per-project settings. That includes personal data, such as account IDs and the answers in a customer's own request. |
| Personal data reporting | The app reports the account IDs it stores to Atlassian each week through the report:personal-data scope, so that everything held for a closed account can be erased. |
| Residency, retention, egress | As for every app above: Forge hosted storage pinned with your product, kept by Atlassian for 28 days after uninstall, no egress, no sub-processor other than Atlassian. |
Mermaid Diagrams & Gantt for Confluence
| Permission scopes | None. The install screen shows no scopes. |
|---|---|
| Stores data | Nothing in app storage. Diagram text, its earlier versions and the picture kept for exports are Confluence page content, stored by Confluence with the page, and located wherever your Confluence pages are. |
| Processing | Diagrams are drawn in the reader's browser, inside a sandboxed Forge iframe, with sanitisation permanently on. One function on Forge returns a diagram's saved picture or text when Confluence needs it outside the live page (an export, an older page version, an email); it makes no network calls and stores nothing. |
| Personal data | None held by the app. |
Reporting, response and support
Vulnerabilities go to [email protected]: acknowledged within 1 business day, assessed within 3, fixed ahead of all other work, with safe harbour for good-faith research. The incident response steps are short on purpose: with no servers of ours and no access to app data, the realistic incident is a defect in an app or a dependency, and containment means shipping a fix or withdrawing a version.
Support targets by severity are in the service level agreement: 1 business day for critical issues and security, 2 for major, 3 for minor. Support is by email, from the person who builds the apps.
What we do not claim
No SOC 2, ISO 27001 or comparable certification, no CAIQ, and no enrolment in the Marketplace bug bounty programme. We would rather say so plainly than imply otherwise. The apps run on infrastructure we do not operate and cannot certify; what we can answer for is what they reach, which this page does.
How to verify
- Permissions: Atlassian's install screen lists every scope before you approve, and your site's Manage apps page shows them afterwards.
- Egress: the Privacy & Security tab of each listing shows "Runs on Atlassian" where Atlassian has confirmed that an app has no egress, and the partner's answers on data storage, residency and retention.
- What is stored: the Issue Templates documentation lists every record with its place and retention, and is updated with each release.
- Questions a questionnaire does not cover: [email protected]. We answer in writing, and add the answer here if it is useful to others.