Atlassian DPA for Jira and Apps: Who Signs What (2026)
On this page
A security reviewer sends the procurement form back with one line: “Please attach the signed DPA from Atlassian and from each app vendor.” Nobody on the team has ever signed one with Atlassian. Three of the five apps on the site have no DPA link at all.
Both halves of that request have an answer, and they are different answers. This post follows one Jira comment through every company that processes it, with the contract that covers each stop. All contracts were read on 14 November 2026. This is not legal advice: it is a map of what the documents say, so you can ask your lawyer the right questions.
Short answer: You do not sign the Atlassian DPA. Atlassian’s FAQ says it “applies automatically when your organization accepts the Atlassian Customer Agreement (ACA), so there is no need to separately sign the DPA”. The current version is effective August 17, 2026, and the EU SCCs and the UK Addendum inside it are deemed signed. It covers Jira, Confluence and the other Atlassian cloud products, plus Atlassian’s own sub-processors. It does not cover Marketplace apps: the Customer Agreement says they are subject to the provider’s terms, “not this Agreement”. For each app, get the vendor’s terms, privacy policy and, where it processes personal data for you, its DPA. A Forge app with the Runs on Atlassian badge keeps your data inside Atlassian; a Connect app or a Forge app with egress sends it to the vendor’s servers. This is not legal advice.
Who signs what
Four contracts can touch one Jira site. You are a party to two of them.
| Contract | Between | How it becomes binding | Your action |
|---|---|---|---|
| Atlassian DPA (August 17, 2026) | You and Atlassian | Automatic with the Customer Agreement (October 1, 2026). SCCs and UK Addendum deemed signed | Save the PDF and the pre-signed SCCs for the file. Subscribe to sub-processor notices |
| App vendor’s terms, privacy policy, DPA | You and each app vendor | “By ordering, installing or enabling” the app (Marketplace Terms of Use 3.1) | Find each one on the listing. If the app processes personal data and has no DPA, ask |
| Forge DPA | The app vendor and Atlassian | The vendor accepts the Forge Terms to use Forge | None. It explains why a Forge app’s stored data stays with Atlassian |
| Marketplace Partner Agreement | The app vendor and Atlassian | The vendor accepts it to list apps | None. It is why every listing must have a privacy policy |
The checklist that follows from it:
- Confirm who accepted the Atlassian Customer Agreement for your organization. That acceptance is your signature on the DPA.
- Download the DPA PDF and the pre-signed SCCs from the DPA page. Note the date. Google’s second result for “atlassian dpa” is still a PDF from January 2023.
- Subscribe to new sub-processor emails on the sub-processor page. The 30 days of notice only reach subscribed addresses.
- List every installed app in Administration, Apps. Write down the vendor, and whether it is Forge or Connect.
- For each app, open the listing’s Privacy and security tab. Save the vendor’s terms, privacy policy and DPA.
- For each app that sends data out, ask for its sub-processor list.
- Repeat for every new app. Installing one is the moment you enter its terms.
Follow one comment
Take a real kind of comment: “Call Anna Kowalski about refund 4411.” It names a person, so it is personal data. Your company decided to collect it, which makes you the controller. Here is where it goes.
Stop 1: Jira stores it. The DPA says “Atlassian is a Processor (or respectively, a Sub-processor) of Customer Data”. It must process the data only on your documented instructions, which include “Customer’s use of the Products (including relevant configurations and settings)”. Where it is stored depends on data residency: “By default, all Atlassian apps are hosted in the Global location”, unless an admin pins the site to a location such as the EU or Germany.
Stop 2: AWS and the backups. The DPA FAQ is direct: “we use Amazon Web Services data centers to assist us in hosting your data”. Clumio is listed as the “Backup solutions provider” for S3, DynamoDB and SQL stores. Atlassian has general authorisation to use sub-processors and “remain[s] liable to Customer” for them (section 4.1). GDPR Article 28(2) is why this clause exists: a processor “shall not engage another processor without prior specific or general written authorisation of the controller”.
Stop 3: Rovo, if you turned it on. The sub-processor list names OpenAI and AWS Bedrock as “Generative AI services provider” for “All Atlassian Cloud Products with Rovo enabled”. Rovo is an Atlassian product, so this stop is still inside Atlassian’s DPA. It is the stop most procurement forms miss. An AI client connected through Atlassian’s MCP server is not: its model provider works under your contract with that provider, as our Jira MCP guide shows. What Rovo agents do with a work item once they read it is in our Rovo agents test log.
Stop 4: a Forge app with no egress. Now an app reads the comment and stores something, say a summary. Forge apps run on Atlassian’s infrastructure. Between the vendor and Atlassian, the Forge DPA applies: Atlassian processes “End User Personal Data” “as a processor or Sub-processor on behalf of Developer”. The same definition adds that this “does not include Personal Data that Atlassian processes as a processor on behalf of Atlassian’s customers”. Our reading: the comment in Jira stays under your DPA with Atlassian; the copy the app stores is processed by Atlassian for the vendor; the vendor answers to you under its own terms. Forge hosted storage “is data residency-enabled”, so the copy moves with the site’s pin. Atlassian marks such apps with a Runs on Atlassian badge. The rule: “Your app must not egress data, with the exception of egress for analytics purposes.”
Stop 5: a Forge app with egress. The manifest’s fetch.backend “declares which external domains
your Forge functions can talk to”. Once it lists one, data can leave. Atlassian’s docs say Forge
“assumes an app stores in-scope End-User Data remotely” if the manifest has an external domain in
fetch, unless the vendor declares otherwise. From here, the vendor’s DPA and the vendor’s
sub-processors apply. Atlassian’s Customer Agreement, section 7.2, is plain about it: use of a
Marketplace app “is subject to the relevant provider’s terms of use, not this Agreement”, and
“Atlassian does not control and has no liability for Third-Party Products.”
Stop 6: a Connect app. Atlassian’s own Connect guide says a Connect app “is usually hosted elsewhere (for example, a cloud platform service like Heroku)”. The vendor’s server receives what the app reads. Atlassian’s data residency glossary calls this “Data from Connect apps that may be stored outside of the Atlassian cloud environment by a third-party app vendor”, and lists it as out of scope for pinning. New Connect apps can no longer be published on the Marketplace, but installed ones still run.
There is one more stop that no DPA on this page covers: the browser. A dictation feature that uses the browser’s speech recognition sends audio from Chrome to Google and from Edge to Microsoft. That is the browser vendor’s terms, not Atlassian’s and not the app’s.
Atlassian’s sub-processors, counted
The sub-processor list says “Effective Starting May 15, 2026”. On 14 November 2026 it had three tables.
| Table | Rows | Distinct companies | Examples |
|---|---|---|---|
| Third-Party Sub-processors | 30 | 26 | AWS, Clumio, Cloudflare, Twilio, Infosys, OpenAI |
| Atlassian Group Sub-processors | 15 | 15 | Atlassian B.V., Atlassian Germany GmbH, Atlassian US, Inc. |
| Government Cloud | 5 | 5 | AWS, Crowd Strike, Google, Okta, Tenable |
The 26 third-party companies by category: hosting and infrastructure 10, communications 8 (email, SMS, push), content delivery 1, support 4, and 3 more that appear only under AI and analytics (Lakeside, OpenAI, Typesafe AI). Four companies appear twice: AWS, Google, Databricks and Twilio.
The list is shared with Forge. It says the sub-processors work for “Atlassian customers and developers”, under the Atlassian DPA “or for Forge, Atlassian’s Forge Data Processing Addendum”. Rows for Databricks, MessageBird, Twilio and SoftServe name Forge as an applicable product.
How we counted. We opened the page in Chrome and counted the rows of each table body. A row whose first cell starts with “Applicable Cloud Products” continues the company above it, so it does not count. Category headings do not count. Then we merged companies that appear under two categories. Counts change when Atlassian adds a company; the 30 days of notice in DPA section 4.2 go only to subscribed emails.
What Atlassian’s DPA promises
The terms people ask about, from the August 17, 2026 text:
| Topic | What the DPA says |
|---|---|
| Breach notice | “without undue delay and, where feasible, no later than seventy-two (72) hours” |
| New sub-processor | Notice “at least thirty (30) days before”, to subscribed emails |
| You object | Your “sole and exclusive remedy” is to terminate the affected product’s order |
| Audit | Reports under NDA; on-site only if reports are not enough, 60 days notice, once every 12 months |
| After termination | Delete all Customer Personal Data, except as law requires or under “standard backup or record retention” |
| EU transfers | EU SCCs (Decision 2021/914), Module Two or Three, Irish law, deemed signed |
| UK and Swiss transfers | UK Addendum “Version B1.0, in force 21 March 2022”, deemed signed; Swiss law version of the SCCs |
| US transfers | Atlassian “certifies compliance with the Data Privacy Framework” |
| Your own DPA | “we are unable to work from your organization’s DPA” |
| Atlassian as controller | For account and profile data, under its Privacy Policy, not the DPA |
Two things surprise people. First, you cannot swap in your own template: Atlassian runs one program for “300,000+” customers. Second, Atlassian is a controller, not a processor, for some data, such as your account and profile. The DPA’s Schedule 1 and its FAQ say so, and point to the Privacy Policy for that part.
What every app vendor owes you
Atlassian sets rules for vendors in the Marketplace Partner Agreement. A vendor must ship “your own End User Terms and End User Privacy Policy with any Marketplace App”. The privacy policy must say how it processes data, with whom it shares it, “in which country or countries the End User Data will be stored” and “that you (not Atlassian) are responsible for your processing of End User Data”. A vendor must tell Atlassian about a security incident “within 48 hours”, and “may not sell any End User Data”.
The agreement does not tell a vendor to offer a DPA. GDPR does, when the vendor is a processor: “Processing by a processor shall be governed by a contract or other legal act” (Article 28(3)). Atlassian’s own developer guide from 2023 says developers who process data for customers “have an obligation under the GDPR to enter into a DPA with their customers”.
Use these questions for each app. Each one has a place where the answer should be:
- Forge or Connect? Listing, Privacy and security tab, or ask. Connect means a vendor server.
- Runs on Atlassian? A badge on the listing and in Marketplace search. Atlassian applies it automatically; vendors do not apply for it.
- Which domains does it call? The install screen and the vendor’s docs. For Forge, the manifest’s
permissions.external.fetchlist. - Where is data stored, by country? The privacy policy must say so (Partner Agreement 8.4(e)).
- Does it move with data residency? The admin’s Data residency page shows each app’s status.
- Who are its sub-processors? The vendor’s DPA. For a no-egress Forge app, usually only Atlassian.
- What happens on uninstall? The privacy policy or DPA. Ask what stays behind, on Atlassian and on any vendor server.
- Which scopes does it ask for? The install screen. Map each scope to a feature.
- How are breaches reported to you? The DPA. The vendor tells Atlassian within 48 hours; your notice is in the vendor’s own terms.
- Does it send data to an AI model? The listing and the DPA. A model the vendor calls itself is egress, and its provider is the vendor’s sub-processor.
Even the badge has limits. Atlassian writes that its egress controls “do not prevent misuse of access granted to the app during installation or abuse of the app runtime”. Read scopes anyway. Our egress post goes through that review step by step, and What to Check Before Installing a Marketplace App covers the rest of a security review.
Data residency: what moves with your pin
Data residency is the part of “where does my data live” that a contract cannot fix on its own. On Atlassian’s data residency page, comments, attachments, issues and field content can be pinned. Some data never is:
- User account information (name, email address, avatar), kept “in a central identity service with globally distributed replicas”.
- App, audit and operational logs, and data in transit for up to 30 days.
- “Some Atlassian Marketplace and app data”: data a Connect app or an outside server keeps.
For Forge apps the rule is simple. “Every persistent Forge hosted storage capability is data residency-enabled”, and an app that keeps its data there “will automatically be located” with a pinned site. An app with a remote backend can still be pinned if the vendor sets up region-specific URLs. Atlassian’s advice for everything else: “We recommend contacting app vendors directly to confirm compliance with your residency requirements.”
Our apps, as an example
We publish 28 apps. On 14 November 2026 our Marketplace vendor page showed the Runs on Atlassian badge on 25 of our 28 apps. The three without it are the three whose manifests list an outside domain, and each says why:
- Team Checklist calls
www.googleapis.comandtasks.googleapis.com, and only for people who connect their own Google Tasks. The checklists stay in Forge storage. - OutSync, for Jira and for Confluence, calls Google’s token endpoint and the
Calendar API when an admin turns on Google Calendar sync. The manifest marks the Calendar calls as
carrying in-scope data (
inScopeEUD: true). Our OutSync data handling post shows what leaves and why it costs the badge. Our Jira and Google Calendar comparison shows the data path of five other ways to get Jira dates into Google Calendar.
The other 25, such as Secret Sentinel, declare no outside domain and no Forge Remote, so stops 5 and 6 do not exist for them. That is the whole point of the badge for a reviewer: the app’s data path ends at stop 4. One honest footnote: Speech to Text has the badge, but the browser’s own speech service hears the audio, as its product page says.
The badge is not a DPA. Two of our apps publish one, such as the Report Assistant DPA; every app has a privacy policy on its product page. If your review needs a DPA for another of our apps, ask us.
The short version
- Atlassian’s DPA is automatic, current as of August 17, 2026, and covers Atlassian and its 26 third-party sub-processors. Subscribe to the notices.
- Every Marketplace app is a separate contract with a separate company. Read its terms and privacy policy, and get a DPA where it processes personal data for you.
- Ask one question first: does the app’s data leave Atlassian? The Runs on Atlassian badge, the manifest’s external domains and the data residency page answer it.
Sources, all read on 14 November 2026: Atlassian Data Processing Addendum, Atlassian Customer Agreement, sub-processors, About the Forge DPA, Runs on Atlassian, Forge permissions, Forge data residency, Getting started with Connect, Marketplace Terms of Use and GDPR Article 28.
Frequently asked questions
Do I need to sign the Atlassian DPA?
No. Atlassian says the DPA "applies automatically when your organization accepts the Atlassian Customer Agreement (ACA), so there is no need to separately sign the DPA." The EU SCCs and the UK Addendum inside it are deemed signed too. If your auditor wants paper, Atlassian offers a pre-signed copy of the SCCs on the DPA page. It will not sign your own DPA template instead.
Is Jira GDPR compliant?
No product is GDPR compliant on its own; a controller uses it in a compliant way. What Atlassian gives you for Jira Cloud is the contract GDPR Article 28 asks for (the DPA, with Atlassian as processor), transfer clauses for the EU, UK and Switzerland, Data Privacy Framework certification, data residency on Standard, Premium and Enterprise, and tools for access and deletion requests. Your apps, your settings and what people type are still yours to manage.
Does the Atlassian DPA cover Marketplace apps?
No. The Customer Agreement says use of Third-Party Products, including Marketplace apps, "is subject to the relevant provider's terms of use, not this Agreement". Each app vendor needs its own terms and privacy policy, and a DPA when it processes personal data for you. The only exception is apps built by Atlassian itself, which fall under the Atlassian terms.
How many sub-processors does Atlassian use?
On 14 November 2026 the list, effective May 15, 2026, named 26 third-party companies in 30 rows (AWS, Google, Databricks and Twilio appear twice), 15 Atlassian group companies and a separate list of 5 for Government Cloud. Which ones touch your data depends on the products you use: OpenAI, for example, is listed for products with Rovo enabled. Atlassian gives 30 days notice of a new one to subscribed emails.
Does data residency cover my Marketplace apps?
Only some. A Forge app that keeps its data in Forge hosted storage moves and stays pinned with the Jira or Confluence site. Data a Connect app or a Forge app with egress keeps on outside servers is out of scope; Atlassian tells you to check with the vendor. User account data (name, email, avatar) is never pinned, for any app.
Does the Runs on Atlassian badge mean an app needs no DPA?
Not by itself. The badge says the app uses only Atlassian compute and storage and sends no in-scope data out. The vendor still decides what the app does with your data and still writes the code, so if it processes personal data for you, ask for its terms, privacy policy and DPA as usual. The badge makes the vendor's sub-processor list short, often just Atlassian.