Organizational Hierarchy Best Practices

Understanding Access Levels

The organizational structure relies on the understanding of how the structure affects users' access to business objects. Generally, users are limited to accessing business objects at their organizational group and below within the organizational hierarchy, but some objects may have additional visibility given their use case. Overall, there are three relationships that organizations can have with other organizations in the hierarchy that will determine users' access level.

Parent Organizations: - Can access objects for all organizations below it in the organizational hierarchy.
Child Organizations: - Can access objects for all organizations below it in the organizational hierarchy, but cannot access objects within the parent organization.
Sibling Organizations: - Cannot access objects within other sibling organizations or any other organizations on the same hierarchical level.

For example, if the organizational hierarchy is structured like the example diagram above, users will have the following access:


Organization	Relation to Other Organizations	Access Level
Global	Parent of North America and Europe	Can access: All organizations in the hierarchy
North America	Child of Global Parent of USA and Canada Sibling of Europe	Can access: North America, USA, Canada Cannot access: Global, Europe, Germany, France, UK, Netherlands
Europe	Child of Global Parent of Germany, France, UK, Netherlands Sibling of North America	Can access: Europe, Germany, France, UK, Netherlands Cannot access: Global, North America, USA, Canada
USA	Child of North America Sibling of Canada	Can access: USA Cannot access: Global, North America, Canada, Europe, Germany, France, UK, Netherlands
Canada	Child of North America Sibling of USA	Can access: Canada Cannot access: Global, North America, USA, Europe, Germany, France, UK, Netherlands
Germany	Child of Europe Sibling of France, UK, Netherlands	Can access: Germany Cannot access: Global, North America, USA, Canada, Europe, France, UK, Netherlands
France	Child of Europe Sibling of Germany, UK, Netherlands	Can access: France Cannot access: Global, North America, USA, Canada, Europe, Germany, UK, Netherlands
UK	Child of Europe Sibling of Germany, France, Netherlands	Can access: UK Cannot access: Global, North America, USA, Canada, Europe, Germany, France, Netherlands
Netherlands	Child of Europe Sibling of Germany, France, UK	Can access: Netherlands Cannot access: Global, North America, USA, Canada, Europe, Germany, France, UK

Access Level Exceptions

For many objects in the OneTrust Platform, access levels will reflect the behavior detailed in the table above. However, some objects are exceptions to these behaviors given their use cases. The following table provides some examples of objects for which users may have additional visibility.


Object	Access Level
Assessments Controls Risks	User can access specific records based on their relationship or assignment to the record. For example, a user with the necessary roles/permissions in the Canada organization from the diagram above will have access to assessments managed by the Canada organization and child organizations. However, if the user is assigned as an approver or respondent to an assessment managed by another organization or if an assessment is shared with the user, that user will have access to the assessment while viewing the Assessments list screen in the Canada organization.
Contracts Engagements Inventories	User can view objects managed by the parent organizations but cannot edit. For example, a user with the necessary roles/permissions in the Canada organization from the diagram above will have access to inventories (e.g. processing activities, assets, legal entities, and vendors) managed by the Canada organization and child organizations. However, they will also have limited view-only access to inventories managed by any parent organizations. In this example, the user within the Canada organization would then have visibility into the inventories managed by the North America and Global organizations.

Things to Know

The following are considerations and best practices to keep in mind when setting up your organizational hierarchy.

Use Organization Naming Conventions

When naming organizations in the organizational hierarchy, it is important to keep in mind that these names will appear throughout the OneTrust Platform, such as in selection fields across different modules. To avoid confusion, it is recommended that each organization have a unique name regardless of where the organization exists within the hierarchy. In addition, commas (,) and semicolons (;) should not be used as part of the organization's name.

If you want to create organizations with similar names, such as Marketing or HR, prefixes can be used to differentiate between the organizations. For example, suppose you want to have multiple organizations named Marketing. A recommended naming solution would be to add a prefix based on the parent entity to make each organization name unique, such as US - Marketing, DE - Marketing, FR - Marketing, UK - Marketing.

Simplify the Organizational Hierarchy Structure

When structuring your organizational hierarchy within the OneTrust Platform, it is recommended to keep the structure as simple and as flat as possible. It is not necessary to identically replicate the way your company is structured when creating the organizational hierarchy within the OneTrust Platform. Doing so may result in the creation of hundreds and/or thousands of different organizations in the hierarchy, which complicates the visibility and management of records for companies that have a large volume of different areas, departments, divisions, etc. by which the company is organized. Instead, prioritize structuring the organizational hierarchy in a way that provides users with the appropriate visibility and access to the records they need at the level they need.

Structuring the Organizational Hierarchy

Best practices often structure the organizational hierarchy per legal entity, whether dictated by a geographical presence, functional areas, or programs. The following sections provide examples of these organizational structures.

Geographical Regions Structure

Structuring by geographical regions with various business units underneath designated regions is most beneficial particularly in the following use cases:

Each country has a designated privacy officer (i.e. the legal entity is defined by region)
Each functional group has a designated resource that reports to the privacy officer of that country

Given the example structure illustrated above, an administrative user within the Global organization would have oversight and access to each of the organizations below it. On the other hand, an administrative user within the Germany organization would only have oversight and access to the Germany organization and the child organizations below it. However, that user would not have access to any of the other countries listed or the Global organization above it.

Functional Groups Structure

Structuring by functional groups with various regions underneath designated functional groups is most beneficial particularly in the following use cases:

Each functional group has a designated privacy officer (i.e. the legal entity is defined by functional group)
Each region has a designated resource that reports to the privacy officer of that functional group

Given the example structure illustrated above, an administrative user within the Global organization would have oversight and access to each of the organizations below it. On the other hand, an administrative user within the HR organization would only have oversight and access to the HR organization and the child organizations below it. However, that user would not have access to any of the other functional groups listed or the Global organization above it.

Program Structure

Structuring by programs with various regions underneath designated programs is most beneficial particularly in the following use cases:

Each program has a designated administrator (i.e. the legal entity is defined by program)
Each region has a designated resource that reports to the administrator of that program

Given the example structure illustrated above, an administrative user within the Global organization would have oversight and access to each of the organizations below it. On the other hand, an administrative user within the Consent & Preferences organization would only have oversight and access to the Consent & Preferences organization and the child organizations below it. However, that user would not have access to any of the other programs listed or the Global organization above it. Furthermore, a designated resource within the Consent & Preferences - Asia organization would only have oversight and access to the Consent & Preferences - Asia organization but would not have access to any of the other regions listed within the same program or the Consent & Preferences organization above it.

Settings & Administration