Your Jira site can be pinned to an approved location while a failed test's screenshot is stored somewhere else. A test-management app may display its records inside Jira yet maintain a separate database, attachment store or backup process. Procurement needs evidence about those records, not reassurance based on the screen where testers see them.
For a Jira Cloud evaluation, define data residency as control over the documented categories of stored data in a specified geographic boundary. That scope does not establish where every processing operation happens, who can access the data, or whether the organization meets its legal obligations. Review those questions separately with security and legal owners.
Use the following checks against the exact app, deployment and edition you intend to buy. Xray Cloud provides concrete documentation examples, but its published behavior should not be assumed for another app or an unverified installation.
Start with the required geographic boundary, then compare it with the app vendor's definition. A country, a broader regional location and an individual cloud region are different procurement requirements. Atlassian's EU location, for example, includes Frankfurt and Dublin, while its Germany location corresponds to Frankfurt. A requirement for Germany cannot be satisfied merely by showing that a product offers an EU option.
The host platform's location list also does not establish the test app's coverage. Atlassian says Marketplace partners decide which locations their apps support. A Jira location available to your organization may therefore be unavailable for a particular app's data.
Xray's Data Residency guide publishes a list introduced with “At the launch”: United States, Europe (Frankfurt), Germany (Frankfurt), and Australia (Sydney). Treat those exact labels as the guide's published launch list, not a guarantee of current availability for every Xray Cloud instance. In particular, do not silently equate its Europe (Frankfurt) label with Atlassian's broader EU definition.
Ask the vendor to confirm the current location choices for the proposed installation and explain their geographic boundaries in writing. Record the current location, required destination, deployment and edition beside that response. If your target is missing from the published list, leave it unresolved until the vendor confirms support; neither availability nor impossibility follows from an omission alone.
A useful review follows the evidence through the testing workflow. A requirement may be a Jira issue, the reusable test may contain app-managed steps, and the failed execution may hold a separate screenshot. Checking only the issue's location can miss the evidence reviewers need to explain a release decision.
Atlassian lists Jira issues and field content, comments and attachments among Jira's pinnable data. That is Jira's scope, not a promise about every record held by an installed test app. Xray's Storage guide says its data is stored separately in a dedicated database. Its rendered storage table assigns issue-level attachments to Atlassian Storage and Test-step attachments and Test Run evidence to Xray Storage.
Use that distinction to build an inventory rather than assigning one region to everything visible in Jira:
Evidence Copy | Documented Xray Example | Location Evidence to Request |
|---|---|---|
Jira issue attachment | Issue-level attachments use Atlassian Storage | Jira scope and pinned location |
Test-step or run evidence | Rendered Storage table assigns these to Xray | App-specific scope and location |
Backup or downloaded export | Storage guide includes attachments in Xray Backup | Backup region, recovery copies, and chosen export destination |
The table identifies evidence questions, not verified locations for your tenant. Storage accounting is also different from residency scope: Xray marks textual result logs, comments, actual results and backups as stored in Xray without contributing to attachment storage usage. A record that does not consume that allowance still needs a location and retention decision.
Historical attachments need separate attention. Xray says attachments created before June 20, 2020 remain in Jira issues and are not migrated to Xray Storage. Ask where the particular retained artifacts live instead of assuming that every attachment follows the current storage arrangement.
Have the QA owner identify representative test definitions, failed runs, step evidence and linked defects, then ask the administrator and vendor to map each record to its storage and residency scope. For a related inventory and retention workflow, see Jira test evidence storage and cleanup rules. Cleanup approval and geographic approval remain separate decisions.
A Jira integration describes a working relationship, not a universal hosting architecture. Atlassian explains that Marketplace partners are third parties and that app data can be stored outside Atlassian's environment. Xray's separate database is a concrete reason to request app-specific evidence even when the team works entirely through Jira.
Ask which system holds each category, who operates that system, and which setting controls its location. The response should distinguish Jira-held records, app-held records and copies sent to other systems. A Jira pinning screenshot cannot, on its own, establish the location of a separate app store. Conversely, a separate store is not automatically unsuitable if its verified controls meet your requirements.
Check version-specific architecture warnings before applying them to a purchase. Xray's Standard and Enterprise co-location warning expressly applies only to non-standalone app versions before Xray Cloud 6.10.0. Do not repeat it as a universal requirement for every current Standard or Enterprise deployment. Ask which installation model the proposal uses and whether any associated components impose a location dependency.
Keep the resulting storage map separate from the wider security review. Request evidence about processing, support access, subprocessors and external integrations where those are requirements. An answer about stored test steps should not be treated as an answer about every support or processing path, and a Cloud finding should not be carried over to a Data Center deployment without appropriate evidence.
A vendor's statement that it supports residency is only the beginning. Atlassian distinguishes four Marketplace app statuses with different implications for an existing installation:
Ask an authorized organization administrator for a dated observation of the proposed app's status and location. Pair that observation with the vendor's scope statement. A successful move of Jira, a supported destination and an app's current pinning status answer different questions; keep them as separate entries in the purchase evidence.
Atlassian configures its data residency at app level, not individually by project, client or user. If your requirement is to segregate customers geographically within one Jira app, do not assume that separate projects supply that boundary. Resolve the deployment design before treating the residency check as passed.
Support for a location at installation does not prove that existing data can be moved there. Atlassian supports combined moves for some Marketplace apps, while others must move separately after the host Atlassian app. In the separate path, the Marketplace partner handles the app data movement.
Xray's guide states that Atlassian supports a combined move of a product and Xray. Use that as a documented capability to discuss, then confirm that the proposed source location, destination and installed version qualify. For apps connected to multiple Atlassian apps, Atlassian says the required Atlassian app determines residency. Identify that required host rather than assuming the Jira screen your testers use determines the location.
Before approving a migration-dependent purchase, request a plan that names the move owner, affected records, completion evidence and escalation path if movement fails. Agree how the team will reconcile a representative test, its execution evidence and linked defect afterward. These are proposed acceptance checks, not a claim that a migration has been tested in your environment.
Include timestamp handling. Xray warns that moving data to a new region updates file dates to the transfer date. Preserve the execution and build context needed to interpret an artifact rather than using its modified date as proof of when testing occurred.
Confirm scheduling requirements directly. The published move documentation uses inconsistent wording about advance notice, so it should not become a universal lead-time recipe. Obtain the applicable booking rules and support responsibilities for your installation before committing to a cutover date.
A residency move can interrupt release testing beyond the app being purchased. Atlassian's Marketplace move guidance says the host Atlassian app will be offline and asks customers to plan for 24 hours offline within a 24-hour move window. It does not guarantee the exact time within that window. For a Marketplace app connected to multiple Atlassian apps, assess the documented impact on all connected apps.
Xray similarly instructs customers to plan for the product to be offline for 24 hours during an app move. It says it aims to complete the move within the window but cannot guarantee the exact move time, which depends on customer data size. Treat this as a planning instruction, not a measured duration or a service-level guarantee.
Have the release owner and administrator identify the consequences before selecting a window. Will testers need Jira to record failures? Will CI attempt to send results while the service is unavailable? Which team will reconcile evidence produced during the interruption? Confirm whether each connector retains and retries results; do not assume that behavior from the residency feature.
Reserve time for verification after access returns. An authorized team should check the reported location and status, open representative test records and evidence, and verify the integrations required for the next run. A completion email is useful operational evidence, but it does not replace checking that the testing workflow is ready to resume. Assign a person to make that decision before the release schedule depends on it.
A current primary-data location does not settle the location of every older copy. Atlassian's named Backup and Restore service illustrates why the backup mechanism and creation history matter. Its documentation says residency support begins April 28, 2026, with new in-scope backups following the app's pinned region under the stated conditions. Backups created before pinning are not moved, and existing backups remain in the previous region after a later region change. Backup policies, post-operation reports and configuration metadata are outside that service's pinnable scope.
Those rules are specific to Atlassian Backup and Restore. They do not establish the behavior of every Jira backup tool or Xray's backups. Xray's Storage guide says attachments are included in Xray Backup, but attachment inclusion does not verify the backup's geographic location, disaster-recovery copies or restore-region restrictions.
Request written answers for the backup and export mechanisms you will use: where copies are stored, whether replicas have different locations, how older copies are retained and deleted, and which regions can receive a restore. Keep an unanswered backup-region question visible even when primary app data is pinned.
Downloaded evidence needs an organizational destination too. Ask the team where exported screenshots, result files and archive packages will be saved and who controls those locations. Include CI artifacts and any onward copies in the inventory when the proposed workflow creates them. Do not assign them an app vendor's residency setting by assumption. If a mandatory geographic requirement cannot be evidenced for a required copy, hold that part of the procurement decision open.
Consider a fictional checkout team that requires its release evidence to remain within an approved geographic boundary. Its Jira location is documented, but its failed-run screenshots are app-managed and its older exports sit in a separate archive. The Jira observation is useful; the app scope and archive location remain evidence gaps. This is an illustrative review, not a customer result or a test performed in a tenant.
Use a short, locally agreed approval sequence:
Choose the app whose documented data boundaries and operating constraints fit the testing evidence you must preserve. When the answer depends on an unknown location, obtain that evidence before approving the purchase rather than relying on Jira's location to fill the gap.
A green automated test history can help a developer identify a safe-looking change while leaving a QA lead unable to answer a different question:…
A checkout test appears under Payments, again in a Smoke folder, and once more under the latest release. When the payment rules change, someone…
A Jira story is Done, a test case is linked, and the related bug is Closed. Can the release owner conclude that the story's…
Create traceable test cases, prepare release-specific test runs, and keep approved coverage current as the product changes.
