At this moment, Atlassian Organizations are considered the highest level in the hierarchy:

• Atlassian Organization -> Site -> Products

In some situations, there is a business need to maintain different parts of the company separate from each other (e.g.: for security reasons). Usually, this requires setting up a different Atlassian Organization, but that results in a few limitations: 

• Each Organization would require a separate Atlassian Access Subscription.
• Without having multiple Access subscriptions, user and group provisioning to the additional Orgs is impossible.
• The same domain can’t be verified in more than one Org.
• The External User Security feature can’t be enabled in additional Orgs where the domain isn't verified. 

The solution to handle those drawbacks is often addressed by merging both Organization into a single org (Option 2 from the image above). However, that also has its downsides: 

• As the Organization grows, it becomes challenging to manage a large number of sites from the Admin UI -> Overview page.

• There is no separation in terms of billing for different business units that have their own separate sites.

• No segmentation in the overview page indicating which Org Unit the site belongs to.

Suggestion:

Implement another hierarchy level, where a parent Org could have multiple sub-organizations being managed by it. The main goal is to provide Atlassian Access capabilities and domain verification to all sub-organization directly from the parent Org. 

Ideally, the sub-organizations would have completely separate user directories and billing. Also, some sort of segmentation in the Admin UI -> Overview page would be necessary to indicate which sites are managed by each Org. 

The concept is somehow similar to what exists in AWS Resource Access Manager (AWS RAM) and Azure Resource Manager (ARM) where resources can be shared between multiple instances.