Atlassian Data Contribution - what the 17 Aug 2026 change means for DORA, NIS2 and AI Governance

Updated: 25 May 2026

What is Atlassian’s “data contribution”? Data contribution is Atlassian’s term for the default-on policy, effective 17 Aug 2026, of collecting metadata and in-app data from Jira, Confluence, Jira Service Management and other cloud products in order to train its AI models (including Rovo and Rovo Dev). The policy affects roughly 300,000 Atlassian customers globally and introduces a four-tier opt-out model: Free, Standard and Premium customers cannot opt out of metadata collection; only Enterprise customers can fully opt out, and even there metadata is on by default.

Atlassian data contribution – the essentials:

From 17 Aug 2026, Atlassian collects two categories of data by default from Jira, Confluence and JSM: metadata (story points, readability scores, semantic similarity, “common patterns” extracted from Rovo Chat) and in-app data (Confluence page titles and bodies, Jira issue titles, descriptions, comments, custom workflow names).
Plan defaults: Free and Standard – metadata and in-app data both on, no opt-out for metadata; Premium – metadata always on (no opt-out), in-app data off by default; Enterprise – both on by default, but full opt-out available (source: official Atlassian page).
Retention runs up to 7 years. After opt-out: in-app data is removed within 30 days, metadata within 90 days, and affected models are retrained within 90 days. Data already absorbed into the weights of models trained before opt-out is not retroactively “unlearned”.
Excluded from data contribution: customers using customer-managed encryption keys (CMEK), Atlassian Government Cloud, Atlassian Isolated Cloud and customers with HIPAA compliance requirements.
Settings rollout: 16 Apr 2026 (start) – 19 May 2026 (settings fully available) – 17 Aug 2026 (collection begins). Atlassian webinar: 28 Apr 2026.
The change touches three governance domains at once: data governance (classification, retention), AI governance (re-use of data for a new purpose under GDPR Article 6(4)) and data sovereignty (location of data and its derivatives, including model weights). Patronusec, as an accredited QSA and a DORA/NIS2/ISO 27001 advisory firm, supports clients in reviewing AI clauses in SaaS contracts and updating ICT third-party registers – from exposure mapping to redrafting exit-strategy clauses in live contracts.

What is “data contribution” and why does Atlassian avoid the term “data collection”?

“Data contribution” is the name Atlassian gave to its default-on policy of collecting customer data for AI model training. The official Trust Center page (atlassian.com/trust/ai/data-contribution) consistently uses phrases like “giving you control over your data contribution” and “so you can adopt AI confidently”. This is a deliberate piece of language design, not an accident.

Three things the word “contribution” does:

It shifts the actor. The customer becomes the “contributor”; Atlassian becomes the recipient. The same technical mechanism described as “Atlassian collects your data to train its models” produces an entirely different negotiation frame.
It implies an act of will. Contribution implies giving. Giving implies consent. In reality, from 17 Aug 2026 the default for Free, Standard and Premium tiers is on (metadata unconditionally, in-app data for Free and Standard); even Enterprise customers, who can opt out, start with metadata switched on by default. Nobody actively volunteered – the grammar is doing the work.
It pre-empts the regulatory conversation. If both parties agree it is a “contribution”, a DPO has a harder time framing it as a new processing purpose under GDPR Article 6(4). If it is “collection”, the question writes itself.

This is not a practice unique to Atlassian. Microsoft, Google, GitHub, Notion, Slack and Salesforce all deploy variants of the same framing in 2026 (“improve apps and experiences for all customers”, “help us make our products better”). The difference is that Atlassian has published unusually transparent documentation – a tier matrix, retention windows, a list of excluded customer types. That transparency makes analysis easier, but it does not change the nature of the transaction.

Patronusec Insight: From our project experience, the most common error in SaaS contract reviews in 2026 is treating contractual language as neutral. The shift from "collection" to "contribution" materially affects which internal committee the change reaches first (procurement, AI governance or the board). In our DORA and ICT third-party risk advisory work we always begin AI-clause reviews by mapping contractual language onto actual processing operations - only then can the supplier be classified correctly in the Article 28 register.

What exactly will Atlassian collect from 17 Aug 2026?

Atlassian groups the data into two categories. Metadata covers “content attributes” (statistical features of content: story-point counts for Jira items, complexity scores for Confluence pages, Jira Service Management SLA values, semantic similarity between pages) and “common patterns” (phrases, keywords and topics extracted from search queries, Rovo Chat conversations – including prompts and responses – and custom configuration data, where these patterns recur across many customers).

In-app data is user-generated content: titles and body content of Confluence pages, titles, descriptions and comments of Jira work items, custom emoji names, custom status names and custom workflow names.

All collected data is, according to Atlassian, “de-identified and aggregated” before being used for training, with direct identifiers (names, email addresses) removed and controls applied to prevent re-identification. Three caveats worth noting:

“De-identified” does not mean “harmless”. Semantic similarity scores in aggregate can reveal product topology, roadmap sequencing and team structure – exactly the kind of intelligence that competitive intelligence teams actively seek to acquire.
Common patterns include Rovo Chat. If internal users employ Rovo Chat to ask questions about clients, processes or strategy, the recurring phrases from those conversations – after de-identification – become training material.
In-app Confluence data is often the most sensitive content an organisation holds. Incident playbooks, vendor scoring matrices, draft board packs, internal process documentation – these are standard Confluence content in mid-sized and larger organisations.

In SaaS exposure reviews carried out for clients under a vCISO engagement, we routinely recommend classification of Confluence and Jira content at the space or project level – only then can the organisation make an informed decision on which areas to exclude from data contribution (where the plan permits) or migrate outside the default scope (for example, to a dedicated environment with customer-managed encryption keys).

What is the rollout timeline and who does Atlassian exclude from data contribution?

Atlassian split the rollout into three stages. All dates are taken from the official atlassian.com/trust/ai/data-contribution page:

Date	Event	What the admin should do
16 Apr 2026	Data contribution settings rollout begins in Atlassian Administration	Check whether the settings are visible for your organisation
28 Apr 2026	Atlassian webinar – walkthrough of the changes	Diary; also available on-demand afterwards
19 May 2026	Settings rollout complete – available to all organisations	A 90-day decision window begins from this date
17 Aug 2026	Collection begins under the configured settings	Default-on for tiers below, per the matrix

Default settings by plan:

Plan	Metadata	In-app data	Metadata opt-out	In-app data opt-out
Free	ON	ON	No	Yes
Standard	ON	ON	No	Yes
Premium	ON	OFF	No	Yes
Enterprise	ON	OFF	Yes	Yes

Excluded from data contribution:

Customers using customer-managed encryption keys (CMEK)
Atlassian Government Cloud customers
Atlassian Isolated Cloud customers
Customers subject to HIPAA compliance requirements

Exclusion means neither metadata nor in-app data is collected, regardless of plan. In practice, for most EU-based organisations (outside healthcare under HIPAA and public-sector administration) the only realistic full-exclusion paths are the Enterprise plan with active opt-out, or CMEK.

Do you know exactly where your organisation is exposed before 17 Aug 2026?

Patronusec delivers SaaS contract reviews focused on AI training and re-use clauses - with a written list of recommended changes for your live contracts, DPIA and ICT third-party register under DORA Article 28. Within 10 working days you receive a written report mapping exposure per supplier, with a list of contracts requiring urgent renegotiation.

Request an AI clause review for your SaaS contracts

What is the difference between data governance, AI governance and data sovereignty?

These are three distinct domains, and most internal policies in 2026 still conflate them. Atlassian’s “data contribution” is a useful stress test because it touches all three at once.

Data governance answers: who owns the data, where does it live, who can read it, how long is it retained? Atlassian’s 7-year retention and 30/90-day deletion SLAs sit here. Classic controls from ISO/IEC 27001:2022 (Annex A.5.12 – classification of information, A.5.34 – privacy and protection of PII) should already cover this. If they do not, the gap is on your side, not Atlassian’s.

AI governance asks a different question: can this data be re-used for a new purpose – in this case, training a vendor’s model – that was not covered by the original lawful basis? GDPR Article 6(4) requires a compatibility assessment whenever personal data is processed for a purpose other than the original one. The European Data Protection Board has repeatedly signalled that training AI on personal data collected for a different purpose is a non-trivial Article 6(4) question. Most DPIAs drafted before 2024 contain no section on AI re-use at all – Atlassian, in practice, forces that section to be added.

Data sovereignty asks the hardest question: when your data is used to train a model, and that model is served from infrastructure in another jurisdiction, where do your data and its derivatives (model weights) legally and physically reside? Schrems II addressed transfers, not training. The EU AI Act, whose general-purpose AI obligations took effect on 2 Aug 2025, requires GPAI providers to publish a summary of training data and to comply with the Copyright Directive – but it does not establish a unified “right to be forgotten from model weights”.

If your AI governance framework cannot answer “is this a new processing purpose?” within a working week, you do not yet have a framework. You have a policy document waiting for its first real test.

Patronusec Insight: From our project practice, the biggest gap is rarely the absence of an AI governance policy - it is the absence of a decision owner. In most mid-sized organisations, when a change like Atlassian's "data contribution" lands, accountability disperses across procurement, security, legal and the DPO, and nobody has the authority to escalate it to the board. In our vCISO engagements we embed AI clause reviews into the regular vendor management cycle, so changes like Atlassian's are caught before the effective date, not after it.

How does Atlassian’s data contribution affect DORA and NIS2 obligations?

For entities scoped under DORA (Digital Operational Resilience Act), this is not an academic discussion. DORA Article 28 requires a register of all ICT third-party arrangements supporting critical or important functions, with specific fields: nature of services, data processed, location of processing, exit strategy, concentration risk.

In most regulated financial firms we work with, Atlassian is in the register – but classified as a “project management tool”. After 17 Aug 2026 that classification is incomplete. Atlassian also becomes a provider that extracts AI training data from systems within DORA scope.

Three concrete updates required in the Article 28 register:

Add an “AI training contribution” field in the supplier record, with the data type (metadata, in-app data), the active plan (Free/Standard/Premium/Enterprise) and the opt-out status.
Update the exit-strategy clause (Article 28(2)(g)). Exit must cover not only data extraction, but also confirmation that residual data is no longer used to train new model versions. Standard 2023-vintage exit clauses do not address this.
Re-assess concentration risk. If Atlassian supports a critical function (for example, JSM as an incident management tool), data contribution also affects the operational resilience assessment, because contract modification (opt-out) now depends on an admin action that DORA Article 30 expects to be documented.

The analogue applies to NIS2-scoped entities: Article 21(2)(d) requires risk management measures to address supply chain security, including security aspects in the relationship between the entity and its direct suppliers. AI training is a new dimension of supply chain security that should be included in the supplier mapping.

From our project experience, an Article 28 register updated for AI training clauses typically flags 5-15 suppliers in the SaaS stack that introduced similar default-on policies in 2026. Atlassian is simply the most visible case.

What should you do before 17 Aug 2026 – a six-question checklist for every SaaS supplier

A checklist for CISOs, Heads of IT, DPOs and Compliance Officers. Run it for every SaaS supplier handling data classified as confidential or above:

Re-use clause: does the current contract permit the supplier to re-use customer data (in any form: raw, metadata, derived, aggregated, “contributed”) to train models served to third parties?
GDPR Article 6(4): if yes, has the DPO assessed the re-use as compatible with the original lawful basis, or as a new purpose requiring a new basis?
Opt-out: what is the opt-out mechanism, on which plan is it available and in what window?
Retention: what is the retention period for data already collected, and what is the deletion timeline after opt-out?
Model weights: are model weights trained on customer data retroactively “unlearned” after opt-out, retrained without that data, or neither?
DORA / NIS2: is the supplier listed in your DORA Article 28 register / NIS2 Article 21 supply chain map with the correct classification (including AI training contribution)?

Most procurement-led supplier reviews skip three or four of these questions. Not because procurement is failing – because the questions require knowledge from three separate domains (contractual, GDPR, regulatory) and no single role typically covers all three.

Your team doesn’t have the capacity to review 20-50 SaaS contracts before 17 Aug 2026?

In our vCISO engagement model Patronusec delivers stack-wide AI training clause reviews for mid-sized and larger organisations - within 15-25 working days, depending on supplier count. The deliverable includes an updated ICT third-party register, a list of contracts requiring renegotiation and a draft AI training clause for inclusion in new contracts.

Book a vCISO scope-assessment call

How does data contribution affect ISO 27001 and existing DPIAs?

ISO/IEC 27001:2022 does not yet require a dedicated control for AI training, but two existing Annex A controls cover the topic directly:

A.5.12 – Classification of information – if your organisation has classified the content stored in Confluence and Jira (which it should, if it holds a valid certificate), that classification is the starting point for the data contribution decision.
A.5.34 – Privacy and protection of PII – if in-app content contains PII (and in most organisations it does: client emails in tickets, contact details in Confluence pages), data contribution falls within the scope of this control.

ISO 27001 auditors in 2026 are beginning to ask questions about AI training. It is not yet a formal requirement, but audit practice is shifting. From our experience guiding clients through ISO 27001 recertification audits, organisations without a documented assessment of SaaS data re-use are increasingly receiving an “observation” (not yet a non-conformity, but a flag for the next audit cycle).

DPIA (GDPR Article 35) is simpler: a DPIA must be updated when the way personal data is processed changes. Data contribution is a clear change. If your DPIA for Confluence and Jira pre-dates 2024, it needs refreshing – with an AI re-use section and a documented Article 6(4) assessment.

Patronusec Insight: Most DPIAs we see in gap-analysis projects before an audit were drafted as one-off documents, without a refresh process. Atlassian's "data contribution" is a practical test of whether the organisation runs a live DPIA process or merely has a document in a folder. In our ISO 27001 and DORA engagements we embed DPIA refresh into the regular cycle, so supplier changes automatically enter the assessment rather than requiring discovery.

Is opt-out enough to limit the risk?

Short answer: no, but it is a necessary first step.

Opt-out (where available) stops future collection and triggers deletion of data already collected within Atlassian’s SLAs (30 days for in-app data, 90 days for metadata, 90 days for model retraining). What opt-out does not do:

It does not retroactively remove your contribution from the weights of models trained before the opt-out date. Atlassian documents this openly – retraining covers models using post-opt-out data, not earlier models.
It does not change the supplier’s classification in the DORA Article 28 register. The supplier must still be recorded as one that may collect AI training data, even if the current setting is OFF.
It does not change the GDPR Article 6(4) assessment for the window between 17 Aug 2026 and the opt-out date. If the organisation enables opt-out on 1 Oct 2026, data collected between 17 Aug and 1 Oct still requires a lawful-basis assessment.
It does not protect against future changes by the supplier. Atlassian may introduce further categories of “data contribution” later – opting out of one does not extend to opting out of another.

n practice, opt-out is “tier 1” of the response. Tier 2 is the ICT third-party register update. Tier 3 is contractual renegotiation with a clause anticipating similar future changes (for example, a requirement for 90 days’ notice before any new category of data collection is enabled).

In DORA projects delivered by Patronusec we recommend that clients add a standard clause to new SaaS contracts – “AI training data use – notice and consent” – requiring the supplier to obtain active customer consent before any new data collection for training purposes, regardless of the supplier’s default UI setting. It is a short clause worth adding to MSA templates for any contract renewed from 2026 onwards.

FAQ

Is Atlassian data contribution the same as OpenAI training on ChatGPT Enterprise data?

No. ChatGPT Enterprise (OpenAI) and Atlassian Rovo apply opposite default policies. OpenAI’s Enterprise/API products do not use customer data to train models by default (opt-in). From 17 Aug 2026 Atlassian does the reverse – default-on for lower tiers, opt-out requiring an admin action. The technical mechanism is similar; the default-state policy is fundamentally different. From an AI governance perspective, it is the difference between “the vendor asks before taking” and “the vendor takes unless you say no”.

Does “de-identified and aggregated” mean my data is safe?

De-identification reduces risk, but does not eliminate it. Atlassian states that direct identifiers (names, emails) are removed and controls are applied against re-identification. That is accurate. At the same time, semantic similarity scores, common patterns from Rovo Chat and aggregated metadata across many customers can – under sufficiently sophisticated analysis – reveal patterns that are not obvious at the level of a single record. This is an area of active academic research. From a compliance perspective the safer assumption is: de-identified data still requires a risk assessment and does not disappear from the processing register.

Can I disable Rovo and Atlassian Intelligence entirely to avoid data contribution?

Disabling the AI product does not disable data contribution. Atlassian collects data at the organisation level, not per AI product. Disabling Rovo means your organisation does not use AI features – but your data may still be collected for the training of models used by other customers. Full exclusion requires opt-out in Atlassian Administration (available for in-app data across all plans, for metadata only on Enterprise) or migration to customer-managed encryption keys / Atlassian Government Cloud / Atlassian Isolated Cloud.

Does Atlassian have to comply with GDPR when collecting data from European customers?

Yes. As a processor (GDPR Article 28), Atlassian must comply with GDPR when processing personal data originating from the EU. The question is not “whether” but “on what basis”. Atlassian relies on its DPAs and its de-identification statement. From the controller’s side (your organisation), responsibility is two-sided: you must assess whether the new purpose (AI training) is compatible with the original purpose (project management) under Article 6(4). This is an assessment Atlassian cannot perform on your behalf.

What happens if my ISO 27001 auditor or PCI DSS QSA finds data contribution enabled?

It depends on context. For ISO 27001, the auditor will check whether information classification and privacy assessment cover the case (controls A.5.12 and A.5.34) – if not, this is likely to be recorded as an observation. For PCI DSS, the position is more sensitive: if Confluence or Jira content contains cardholder data (CHD) or sensitive authentication data (SAD) – which it should not, but in practice sometimes does – data contribution may amount to a serious finding. Based on our work as an accredited QSA we recommend that PCI DSS clients adopt a clear opt-out from in-app data and audit Confluence/Jira content for CHD/SAD ahead of the QSA assessment.

How much does an AI clause review for SaaS contracts cost at Patronusec?

The price depends on the number of SaaS suppliers in scope, contract complexity (standard supplier DPAs versus negotiated MSAs) and the deliverable required (a report only, or also redrafted clauses for renegotiation). After a free 30-minute scope-assessment call we issue a fixed-price quote with a guaranteed delivery date. For clients running a full DORA or NIS2 programme with us, the AI clause review is included in the package at no additional cost.

How do I start working with Patronusec on AI governance and DORA third-party risk?

The first step is a free 30-minute scope-assessment call. During the call we cover: the current state of the ICT third-party register, the number of SaaS suppliers in scope, existing DPIAs and GDPR Article 6(4) assessments, and the expected timeline. After the call you receive a written scope proposal and a fixed-price quote. For most mid-sized organisations the full AI governance review programme (contract review + register update + draft clauses + team training) takes 4-8 weeks.

Atlassian data contribution and AI governance – free consultation

Patronusec, as an accredited QSA and a DORA/NIS2/ISO 27001 advisory firm, supports mid-sized and larger organisations in mapping the exposure created by default-on AI training policies across their SaaS supplier base. We work with clients in fintech, retail, e-commerce and financial services.

In a free 30-minute consultation we will help you to:

Map which of your SaaS contracts require urgent review before 17 Aug 2026
Determine whether “data contribution” by your suppliers qualifies as a new processing purpose under GDPR Article 6(4)
Identify suppliers that must be added to the DORA Article 28 register / NIS2 Article 21 supply chain map with the correct AI training classification
Plan updates to existing DPIAs and exit-strategy clauses in live contracts

Book a free consultation | DORA advisory | NIS2 advisory | ISO 27001 | vCISO on demand

Blog space

Atlassian Data Contribution: what the 17 Aug 2026 change means for DORA, NIS2 and AI Governance

In this article you will learn