Evidence: the paperwork written before anything moves

Data residency: what the pin covers — and what it does not

Jira, Jira Service Management and Confluence support data residency on Standard, Premium and Enterprise plans. In-scope data — issues, comments, attachments, board and sprint data, search indexes, project configuration — can be pinned to the EU (Frankfurt and Dublin), Germany, the UK or Switzerland, among other realms. Do nothing and you get "Global": Atlassian places data dynamically across its AWS regions.

A defensible assessment also names what the pin leaves out: user account details — name, email, avatar — held in Atlassian's global identity service; product-level app, audit and operational logs, though Atlassian Guard audit events can now be pinned; AI-related data; and cached content such as emails and notifications, held for up to 30 days. The sharpest caveat is apps. Marketplace app data is pinned only where the individual vendor supports residency, so a Jira site pinned to Frankfurt can still be running apps whose data lives elsewhere — map it app by app rather than assuming the pin covers the estate. Encryption belongs on the same page: customer-managed keys are an Enterprise add-on, and your assessment should state whether you need them.

The DORA file, article by article

DORA has applied to EU financial entities since January 2025, and a Jira Cloud subscription sits squarely in scope as an ICT third-party arrangement. The file breaks down cleanly:

• Article 28(3) — an entry in the register of information, subcontracting chain included. Atlassian's Trust Center publishes a sub-processor list and DORA-specific documentation to draw on.
• Article 28(4) — a pre-contract assessment of criticality, risk and due diligence, done before signature.
• Article 30(3) — where the supported function is critical or important, contract terms covering audit and access rights, precisely described service levels and transition periods.
• Article 28(8) — for that same classification, an exit strategy that is written down, tested and reviewed on a schedule.

Only you can classify whether Jira supports a critical or important function — and everything downstream, from notification through contract terms to the exit strategy, depends on that call, so make it early and in writing. Two calibration points keep the file honest. There is no "DORA certificate": the regulation creates no certification scheme, so treat any claim of one as marketing. And compliance is shared responsibility — Atlassian contributes SOC 2 Type II reports under NDA, ISO/IEC 27001:2022 certification extending to ISO 27018 controls, and one concentration-risk fact worth recording: AWS, which hosts Atlassian Cloud, is itself under DORA's oversight framework as a designated critical ICT third-party provider — Atlassian is not. Accountability for the arrangement stays with you.

A regulated change, with the pack written first

DORA Article 9 requires that changes be recorded, tested, assessed, approved, implemented and verified in a controlled manner. A platform migration is squarely that kind of change, so run it as one, with the evidence pack finished before the first production run rather than assembled retrospectively for the auditors. Ours contains:

• the app assessment, with the decision recorded against every app;
• the residency mapping described above;
• test-migration results with measured durations — the numbers the change board will actually ask about;
• the cutover runbook, with named owners against every step;
• the rollback plan — real in a phased migration, because the old instance remains untouched and read-only until formally decommissioned;
• post-migration verification results.

Two audit-trail specifics catch teams out. Export the source records you rely on before the old instance is decommissioned. And the Cloud organisation audit log retains activity for up to 180 days — if your retention policy demands more, configure regular export or SIEM streaming via webhooks from day one, not month five. On Enterprise plans, release tracks bundle most visible product changes into a monthly release previewed in sandbox first — which is how change control survives on a platform that would otherwise update continuously.

Next step: Rehearse

The pack is a skeleton until it has numbers in it. The measured durations, the verification results and the confidence behind the rollback plan all come from full test migrations against production-scale data — that is the next step. Rehearse is where the evidence stops being a plan and starts being proof.

The homepage FAQ answers on EU data residency and on DORA obligations are this step condensed to two paragraphs — this page is the working detail behind both.