Security reviews stall migrations. Not because Jira Cloud can’t pass them – it can – but because enterprise procurement teams ask questions that no one on the migration project has thought through, and suddenly a go-live date turns into a two-month standstill while everyone scrambles for answers.
These questions aren’t hypothetical. They come up in migrations, in InfoSec reviews, and in the conversations your Jira admin is having with your IT team right now. Some of them have clean answers. Some of them reveal gaps worth knowing about before you commit to a timeline.
We’re Tempo Software, a leading provider of strategic portfolio management (SPM) solutions trusted by 30,000+ customers and 350+ global solution partners. That means we get a lot of questions from customers.
We wanted to share five of the most common ones, with honest answers to each.
1. Is Jira Cloud SOC 2 compliant? What about our app data?
InfoSec teams don’t just want a yes. They want to know what’s actually covered by the certification and whether their app data falls under the same umbrella.
Atlassian Cloud is SOC 2 Type 2 certified and ISO 27001 compliant. That covers the infrastructure, the platform, and Atlassian’s own data handling practices. When enterprise security teams ask this question, they’re usually satisfied after reviewing the Atlassian documentation and trust center.
However, things can start to get a little trickier if your teams start asking about the apps running on top of Jira. The compliance posture of each app matters independently of Atlassian’s. For example, Tempo and Rewind also maintain SOC 2 Type 2 certifications and trust centers, but that’s not true of all apps.
One thing worth clarifying before your review: SOC 2 compliance tells you that controls exist and have been audited. It doesn’t guarantee that your data is backed up, recoverable, or protected from mistakes inside your own organization. Those are separate questions, which we’ve got answers to.
2. Where will our data actually live?
For companies operating in the EU, healthcare, financial services, or regulated industries, data residency is a legal requirement. They need to know that data won’t leave a specific jurisdiction.
Atlassian offers data residency controls for Jira Cloud and Confluence, letting customers pin their data to specific regions, including the EU and Australia.
Tempo data residency follows the same regional infrastructure, but your Tempo admin should verify the specifics for your configuration – especially if you’re migrating from a Data Center instance where data was stored entirely on-premises.
Atlassian gives enterprise customers control over where their data lives, but it’s worth understanding the boundaries. Data residency applies to data at rest, and it doesn’t cover every data type in every Atlassian product. Your team should confirm exactly which data types fall under residency controls for the specific products you use.
There’s also a subtler boundary around backups. With Atlassian’s native tools, your backup location is tied to your app’s pinned region. What helps is to decouple the two, so your backups can live in the region you choose, with data residency options across the USA, EU (Germany, Switzerland), UK, Canada, and Australia.
Data residency and data backup are not the same thing. Knowing where your data lives doesn’t tell you what happens to it if something goes wrong. That’s the next question.
3. What are Atlassian’s RTO and RPO commitments? Does that cover Tempo?
Enterprises in regulated industries need to know how quickly they can recover from a failure and how much data they might lose in a worst-case scenario. These aren’t abstract concerns – they feed directly into business continuity plans and audit requirements.
Atlassian publishes uptime SLAs and has documented disaster recovery procedures for the Cloud platform. For the infrastructure layer – the servers, the database, the network – they have defined recovery objectives.
Here’s where it gets more specific: Atlassian’s recovery commitments apply to the platform. They cover outages, infrastructure failures, and Atlassian-side incidents. They don’t cover data lost because someone in your organization deleted a project, a configuration change wiped a year of capacity planning data, or a migration script overwrote records that took months to build.
The gap between “Atlassian recovered from an outage” and “our specific Jira data was restored to the exact state we needed” is what Rewind fills. Rewind maintains independent, point-in-time backups of your Jira data on a schedule you control.
Its own RTO and RPO commitments operate at the app data layer, not just the platform level. For customers going through formal business continuity reviews, Rewind documentation alongside Atlassian’s SLAs often closes the conversation.
4. Who’s responsible if our data is lost or corrupted?
Enterprise IT teams ask this one because they’ve been burned before. They want to know exactly where Atlassian’s responsibility ends, and theirs begins.
Atlassian, like every major cloud provider, operates using a shared responsibility model. Atlassian is responsible for the platform’s security and availability, but you are responsible for how you use your access to that platform.
If your data is lost because of an Atlassian infrastructure failure, that’s on Atlassian. If your data is lost because an admin accidentally deleted a project, a migration went sideways, or a user made a mistake that overwrote something critical, that’s on you.
This isn’t unique to Atlassian – it’s how AWS, Salesforce, Google Workspace, and virtually every SaaS platform works. But enterprise teams often go into cloud migrations assuming “the cloud handles backups” the way their on-premises backup solution did. It doesn’t. The cloud handles infrastructure resilience, not application-layer data recovery.
You own the application layer. That’s exactly why an independent backup matters, as it’s the difference between a mistake being your fault and a mistake being fixable.
5. What actually happens to our Tempo data during the migration?
Most enterprise teams assume migration tools handle everything. They want confirmation that their timesheet history, capacity configurations, and logged hours will arrive in Atlassian Cloud exactly as they were in Data Center.
They won’t be – at least not automatically.
Jira’s migration tools are built to move Jira issues, boards, workflows, and project configurations. They do that job well. Tempo data, like timesheets, logged hours, capacity planning configurations, and approvals, lives in a separate data layer that migration tools aren’t designed to handle. Unless your team has explicitly planned for Tempo data migration as its own workstream, that data stays behind and would require manual REST API exports to recover.
This is the question that most often catches enterprise teams off guard, because it only surfaces once the migration is underway or complete. At that point, you’re not answering a procurement question – you’re managing a data recovery situation.
If you want to see some more best practices – Tempo’s migration specialists hosted a webinar which is now available on demand.
Getting your team aligned before the questions start
Most of these questions have clean answers: SOC 2 is documented, data residency is configurable, and the shared responsibility model is standard across the industry. The two that need real attention before a security review are RTO/RPO and Tempo data – and both come down to the same question: If something goes wrong, can you get your data back?
Tempo has supported nearly a thousand customer cloud migrations, and the one pattern that trips teams up every time is treating Tempo data as an assumption instead of a deliverable.
Audit what you have, get your Jira migration team and admin aligned on a plan, and back up your Tempo data independently before cutover.
Vic Chynoweth">
