Data Residency for Jira Apps: A Compliance Buyer's Guide

Jira Cloud supports formal data residency — you can pin your tenant to the US, EU, AU, and other Atlassian regions. Forge apps honor that pinning automatically because they run inside Atlassian's tenant. Connect apps often don't — the vendor's servers can live anywhere. If your compliance framework cares where data sits, the architecture choice is the control.

Cluster page under the pillar Forge vs Connect: A 2026 Security Guide. Read it for GDPR reviews, public-sector procurement, or financial-services vendor-risk assessments.

What does “data residency” actually mean for Atlassian customers?

Data residency is the rule that a specific copy of your data lives — and stays — in a named geographic region. It's separate from encryption and access control, which apply wherever the data sits. Residency answers the geographic question: where does the byte physically sit, and whose laws can compel its production. It matters for GDPR (cross-border transfers of personal data are a regulated event), for public-sector contracts that require sovereign data handling, and for regulated industries inheriting residency obligations from customer contracts.

How does Jira Cloud's residency feature work?

Jira admins can pin a tenant to a supported Atlassian region. Once pinned, product data — issues, comments, attachments, user directory, workflow configuration — stays in that region, per the residency documentation. Supported regions in 2026 include the US, EU (Germany/Ireland), Australia, UK, Germany specifically, Japan, Korea, Canada, Switzerland, and more. Pinning is tenant-wide, not per-project. Some data types (logs, anonymized telemetry) may still be processed globally under the data management policy, so read the fine print — for the primary product data auditors care about, pinning is binding.

How do Forge apps inherit residency by default?

When a Forge app is installed on a pinned tenant, the platform provisions its runtime — Forge SQL, Forge KVS, scheduled jobs, event queue, function execution — inside the same region. There is no vendor knob to change this; see the Forge security docs. For a compliance reviewer, Forge residency is a platform property you audit once, not a per-app vendor property.

Honest caveat: if a Forge app declares an external.fetch — e.g. an external LLM, a Slack webhook, a reporting tool — and the admin approves it, data sent over that fetch leaves Atlassian and is governed by the destination host. Read the external-fetch block before assuming zero-egress.

Why don't Connect apps inherit residency automatically?

Connect apps run on vendor-hosted infrastructure — AWS, GCP, or Azure in a region the vendor chose. When a Connect app caches Jira data, those bytes land in the vendor's region, which may or may not match your pin. Many large Connect vendors run mature, regionalized infrastructures, but under Connect residency is a vendor property to verify per app. Under Forge, that row collapses back into the Atlassian platform row you already had.

What should you ask a Connect vendor about data residency?

Six questions separate serious vendors from wishful ones: production cloud provider and region; whether customers can pin app data to match Jira; sub-processor list (including monitoring and support tooling); GDPR transfer mechanism (SCCs, adequacy, or BCRs); uninstall data-deletion SLA in writing; and whether the vendor has been audited on residency specifically, not just under a general SOC 2. If a vendor can't answer in a week, that signals how seriously they take regulated buyers.

How does this play into GDPR, Schrems II, and public-sector contracts?

Under the GDPR, transfers of EU personal data outside the EU require a legal mechanism. Schrems II (2020) invalidated US Privacy Shield and raised the bar on SCCs. For a Forge app on an EU-pinned tenant with no external.fetch, data never leaves the EU and Article 44 doesn't apply. For a Connect app hosted in the US, you have a transfer and need the mechanism documented — Atlassian's GDPR center is a useful benchmark. FedRAMP or IRAP buyers should treat residency as necessary-but-not-sufficient: the certification must cover the app, not just the host platform.

A 7-item buyer's checklist

Confirm your Jira tenant's residency pin. Verify the Atlassian region in Jira admin; document it.
Identify each app's framework. Forge-native or Connect — treat this as a hard filter.
Forge apps: read the external.fetch block. Empty = zero-egress. Populated = verify each domain; flag third-party LLMs.
Connect apps: request hosting region and sub-processor list. In writing. Confirm against the DPA. No answer in a week is disqualifying for regulated workloads.
Verify the DPA and GDPR transfer mechanism. If hosted outside your jurisdiction, the DPA must name the mechanism (SCCs, adequacy, BCRs).
Check certifications. SOC 2 Type II, ISO 27001, ISO 27018, plus FedRAMP, IRAP, or CJIS for public sector. Forge inherits platform certs; vendor SDLC is separate.
Document the posture in your vendor-risk record. Per app: framework, effective region, egress destinations, DPA status, transfer mechanism, certifications.

Where Foundation fits

Foundation is Forge-native and, in MVP scope, declares no external.fetch — its Forge SQL, Forge KVS, and event handlers live inside your Jira tenant's assigned region. Pin to the EU, Foundation sits in the EU; pin to Australia, it sits in Australia. See Foundation security, why Forge apps don't store data outside Atlassian, and Forge and Cloud Fortified explained.

Frequently asked questions

Does a Forge app keep my data in the same region as my Jira tenant?

Yes by default. When your tenant is pinned to an Atlassian region, any Forge app there has its Forge SQL, Forge KVS, and function execution provisioned in the same region. Caveat: if the app declares an approved external.fetch to a third-party domain, data sent to that destination follows the destination host’s residency, not yours.

Do Connect apps honor Jira data residency?

Not automatically. Connect apps run on vendor-hosted infrastructure; the vendor chooses the region. Some let customers pin app data to match Jira, others host globally. Verify vendor-by-vendor against the DPA and sub-processor list. Treat “we support EU residency” as a starting point for diligence, not a final answer.

Is Jira data residency enough for GDPR?

It is a key control but not a complete answer. GDPR Article 44 restricts transfers of EU personal data unless an approved mechanism (adequacy, SCCs, BCRs) is in place. A Forge app on an EU-pinned tenant inherits Atlassian’s boundary. A Connect app hosted outside the EU needs its own documented transfer mechanism.

If a Forge app uses a third-party LLM, does data stay in region?

No. A Forge app that calls an external LLM via external.fetch sends the payload to that provider, where the LLM vendor’s residency policies govern — not Atlassian’s. Ask which fields leave, which provider receives them, and whether it respects your regional boundary.

Which Atlassian regions support residency pinning today?

As of 2026: US, EU (Germany/Ireland), Australia, UK, Germany specifically, Japan, Korea, Canada, Switzerland, and additional regions. Not every product supports every region at once — check the Atlassian support page. FedRAMP and IRAP are separate from standard residency.