Object roles and permissions
Compliance programs often contain sensitive information that must be restricted to specific teams or individuals. For example, a manager of a security program may not be allowed to view a privacy program.
To participate in an object, members of an organization, except administrators, must be explicitly added to it and given a specific level of access.
Note
Administrators can change their role on an object at any time. To give a user view-only access to objects in Hyperproof, configure their organization role as compliance manager or user.
A note about proof
Proof that contains sensitive information can be made private, preventing anyone who is not a direct member of that proof from accessing it, regardless of their object-level role.
Additionally, the object-level role on a request or control overrides the permissions on an individual piece of proof.
Hyperproof has the following object-level roles:
Manager
A manager manages a particular object and its members. Managers can perform nearly every function within the object they manage.
Note
The person who creates an object in Hyperproof, such as a control, becomes the manager of that object by default.
Contributor
A contributor performs certain activities in an object that they’ve been added to, such as linking, importing, and exporting.
Note
In the Audits module, managers have access to all proof within an audit.
To view audit proof, you must be a manager of the audit. If you are the manager of a request, but a contributor of the audit, you cannot view proof linked to the request. This helps protect sensitive data that some users shouldn’t see. As a result, only managers can export audit proof.
Viewer
A viewer can view files and information for objects where they are a member and on inherited objects. For example, if a user is added as a viewer to a control, they will have access to all of the proof on that control. Viewers can export data from a grid view for objects where they are members or have inherited access.
If a user has a combination of object roles, such as a viewer role for one object and a manager role for another, note the following:
If a viewer selects objects in a grid view where they have different object roles, such as viewer and manager, they may not have sufficient permissions to perform bulk edits. For example, if the user is a viewer on one selected control and a manager on a second control, attempting to bulk edit both generates a message indicating the number of selected items that can and cannot be updated.
When users are members of related objects, the highest object role is used. Suppose a user is a viewer on an object and a manager on a parent of that object. In that case, they inherit the highest permission of the two objects, allowing edit access.
As shown in the following image, the user is a contributor on a program ABC and its associated requirements but is a direct viewer on control 1.2.3.4 linked to those requirements, the user inherits contributor access to the control. Click the inherited parent link to see the inherited role and the object that provides that inherited role.
