HIPAA compliance using multiple sites?

Question

Our org currently has Jira, Confluence, and JSM. We are actively pursuing use of AI in the environment. We want to launch a HR portal to handle leaves of absence, and want to have it HIPAA-compliant. Atlassian does not certify HIPAA compliance when AI is enabled in a site.

I want to setup a second site for the HR project (example-hr.atlassian.net), which would separate it from the other apps, however, I need to be able to manage user access the same as in our primary site (example.atlassian.net), using Guard (Standard).

I do not see a way to verify our domains for the second/new instance since they've already been verified for the primary.

I have to believe we're not the first to try to need to do this. Is there something I'm missing in order to accomplish this?

Lindsay Bolan · Answer

I forgot to mention what I learned about managing different sets of accounts from a single domain on different orgs.

First, any accounts already claimed by another org can't be claimed by another org, but you do need to check the settings for claiming new accounts on both orgs. I had to set both orgs to not automatically claim new accounts so I wasn't grabbing users outside of my division, but in order to capture the new accounts that do belong to my division, I use a sync group from my IdP (Microsoft Entra). Any Atlassian account synced from an IdP group will be automatically claimed, IF they are from a domain you have verified and they have not already been claimed by another org. You can still include accounts in the synced group that don't belong to you, if you need them to have access to your site.

The usefulness of this will depend on how you manage groups in your IdP. I'm lucky to have data-driven feeds available to me from our HR software, so I can just pick the relevant populations and occasionally check in to verify I'm getting all the right people.

The downside to this is that managed accounts which are removed from your sync group will be deactivated. This is not ideal for a distributed environment if the person still needs access to Atlassian but their account isn't immediately claimed by another org. In Entra, there was a flag we could set to desync but not delete. The problem with that is the desynced accounts remain claimed by my org, which we also don't want. I do not have a solution to automatically unclaim desynced accounts, but I also haven't had much time to look into it.

Darryl St_ Pierre · Answer

Thank you for this information! The few articles I've found made it seem as if something like this couldn't be done, but I think they were older.

I will approach this with an eye toward what you've laid out.

Lindsay Bolan · Answer

I would first check with your legal/contracts team (whoever signed the BAA) to get their risk review, but I can give my perspective as an admin who established two separate cloud orgs because I wanted to host SSO/user provisioning separate from my active Jira/JSM/Confluence site.

Atlassian Intelligence and Rovo are activated on a per-app basis, so you could possibly just create a new site under your existing org and purchase a separate JSM app license which you would not tag for HIPAA compliance under Settings > Compliance in Atlassian Administration. You could then activate AI and Rovo for that separate app while sharing a user and group directory with your HIPAA-compliant site and apps. No need to set up a new SSO/user provisioning IdP; no need to fuss with managing which org should own which accounts.

I chose to use separate cloud orgs because I am operating in a distributed IT environment, and I did not want to manage all of the university's users on my org when I know other distributed groups have set up their own cloud orgs and would want some control over managing their users.

I'm happy to talk more about my setup if you're interested.