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?
Since 2024 the same domain could be verified by differents organization, I have tried it personally and I can confirm it.
Moreover it is reported here https://community.atlassian.com/forums/Articles/Multiple-orgs-can-verify-and-claim-users-from-the-same-domain/ba-p/2688009
The only limitation is that a user can be set as managed accounts in only one organization at same time.
The procedures to verify the domain in the second site is the same: https://support.atlassian.com/user-management/docs/verify-a-domain-to-manage-accounts/
I hope it helps
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.