Orgvue data security

This article provides an overview of how data is shared securely with colleagues and project team members. 

• An overview of Orgvue security is provided.
• The application of User Groups for effective data security is introduced.
• The different approaches for sharing data securely are outlined.

Separate articles explain how packs are shared with Users and how you can See the effect of Permissions granted to Users.

Orgvue Security Overview

Data security is managed at three levels in Orgvue:

1. Tenant Security

• A Platform Role is needed to access an Orgvue Tenant.  There are two Platform Roles:  ‘Admin’ and ‘User’.
• Admins can see all data saved in a tenant; nothing can be hidden from an Admin.
• No restrictions can be placed on the actions which Admins can take.  
• The data Users can see and the actions Users can take is controlled through Dataset Permissions and Node and Property Security.

2. Dataset Permissions

• User access is managed for each individual dataset.
• Until access is provided, only Tenant Admins and Dataset Owners can access a dataset.
• The changes which Users can make are controlled through individual Dataset Permissions.  The minimum Dataset Permission is ‘Read-only’ access, with the further levels being ‘Update’, ‘Manage’, and ‘Modify’.  (These terms are explained below).

3. Property and Node (Column and Row) Security

• Beyond Dataset Permissions, additional security can be applied to control the properties (columns) and nodes (rows) which are visible, and the actions which can be taken by Users.

As a minimum, for data to be shared, the recipient must be added to the Tenant with a Platform Role, and if they are added as a ‘User’, Dataset Permissions must also be granted.

The example below shows,  

1. Three ‘Users’ (in addition to the ‘Admin’).  This status alone does not provide ‘Users’ with access to data.
2. ‘Users’ have been granted ‘Modify’ permissions for a dataset.  Sammy, Neil, and Jan can modify this dataset.  Access to other datasets can be granted by entering the ‘User’ tag at the required level of permission.

User Groups

As seen above, is it possible to apply the ‘User’ Platform Role to manage dataset permissions. 

However, this category is usually too broad for effective data management and data security.  There are typically different groups of Users, each with different access requirements.  Assigning ‘Users’ to ‘User Groups' provides a further level of definition to manage permissions.

The earlier example now shows ‘User Groups’ with different Dataset Permissions:

1. Users in the ‘HRBP’ User Group have only 'Read-only' permission;
2. Users in the ‘Planning’ User Group can 'Modify' the Dataset.

Defined User Groups are foundational for each of the four data security methods outlined in the following section.  They are used to efficiently manage the data which can be seen, and the actions which can be taken by Users.  As such, identifying the required User Groups is a critical step for establishing your data management model. 

The key questions for identifying User Groups are:

• What data do different users need to see; and what data needs to be hidden?
  • Are there properties (columns) with sensitive data needing to be hidden (e.g., compensation values; personal data)?
  • Are there nodes (rows) needing to be hidden (e.g., executive leaders, peer colleagues)?

• What actions do different users need to take with the data they can see?  
  • Is ‘read-only’ access sufficient?  e.g., for analysing the current organization without changing the underlying data, or
  • Do users need to edit nodes?  e.g., adding, removing, and changing positions to correct data quality issues, or modelling the future organization
  • Do users need to add and remove properties in the dataset, change the metadata (e.g., specifying the name of the dataset and the dataset type) and manage dataset permissions?

Note:  A User can be a member of multiple User Groups.  In the illustration above, Sammy is in both the ‘Finance’ and ‘Planning’ User Groups.
 

Orgvue data security methods

There are three ways to manage data security:

1. Role-Based Access Control (RBAC)
2. Views
3. Attribute-Based Access Control (ABAC)

Role-Based Access Control (RBAC)

Using RBAC, access to data and the actions which can be taken is controlled based on User Groups comprised of users with like roles and shared requirements. 

An example of RBAC was seen above with the example of different Dataset Permissions being granted to different User Groups.  Beyond the ‘Dataset Permissions’, ‘Property Permissions’ can be specified for User Groups. Access to Views and Drafts (see below) is also controlled through User Groups.

The illustration below summarizes:

1. The different ‘Dataset Permission’ levels;
2. The ‘Property Permissions’ which can be applied to further restrict Dataset Permissions.

Note: 

• Property Permissions are only ever used to further restrict Dataset Permissions.  If Dataset and Property Permissions are in conflict, Dataset Permissions take precedence.  For example, if a User Group with, ‘Read-only’ Dataset Permission is granted Property Permissions which allow property values to be edited, the conflicting Property Permission will not apply; the dataset will remain 'Read-only' for the User Group.

Views

A View is a read-only extract of a Dataset.  Views can be used for analysis and visualization, but the underlying data cannot be edited.  Views enable dataset integrity to be maintained.

Multiple views can be created from the same Dataset. 

• Separate Views can be created for Subgroups of nodes (rows).  For example, different functions/ business units/ management reporting lines. 
• Views can include all dataset properties (columns) or be limited to exclude sensitive data such as salaries and bonuses.

The illustration below shows the scope of different Views created from the same dataset:

1. The full dataset:  Every property (column) and every node (row) is included.
2. Defined subgroups:   Only the nodes (rows) which are in a defined subgroup are included.  Every property is included. 
3. Specified properties:  Only specified properties are included (e.g., sensitive personal data is excluded).  Every node (row) is included.
4. Defined subgroups and specified properties.  Only the nodes (rows) which are in a defined subgroup, and only specified properties are included.

Note: 

• Drafts can be created from Views to provide a safe space for editing data and overcome the ‘read-only’ status of Views.  
  Views are live extracts of datasets:  When dataset property values are edited, these update in any Views created from the dataset.
• Only Admins, Dataset Owners, and Users with ‘Manage’ Dataset Permissions can create a View.

Attribute-Based Access Control (ABAC)

ABAC involves building custom rules to accommodate permissions which cannot be provided through RBAC, Views and Drafts. 

RBAC, Views and Drafts rely on being able to identify:

• Subgroups of the organization:  Nodes (rows) with shared characteristics, for example every position in the HR function, or at a more granular level, every HR position located in New York; and/ or
• Properties to be included or excluded in entirety.

But an even more granular level of permissions may be required; permissions may need to be restricted based on data attributes.  For example:

• The User Group ‘HRBP’ has been granted permission to a dataset containing a ‘Salary’ property.
• HRBPs need to see ‘Salary’ values, but 
• HRBPs need to be prevented from seeing the ‘Salary’ values for their peers (here ‘peers’ may be defined as anyone in HR/ anyone at the same grade or a higher grade/  other HRBPs, etc.)

ABAC is the least flexible data security method as it requires custom development by the Orgvue Engineering team.  However, after the custom logic has been developed, the permissions can be managed in Settings.

Related articles

• Adding users to a tenant
• Assigning dataset permissions
• Applying property permissions
• Creating a View
• Creating a Draft
• Sharing Packs
• See the effect of Permissions granted to Users