Skip to main content

Audit Facepile

Facepile shows who has access to an audit, and users with the right permissions can add, remove, or change roles.

Danielle Moerman avatar
Written by Danielle Moerman
Updated over 3 months ago

Navigating the Facepile within an audit

All objects in Hyperproof have a Facepile that can be found in the upper-right-hand corner when clicked into an area or object. From here, you can control who has access to the object and what type of permissions they have. You'll use the Facepile any time you want to add a user to an object or adjust a user's permissions on a particular object.

Note: the video tutorial below demonstrates the Facepile within a program. However, the concept is similar for audits. The difference is you'll navigate to the audit tab and click within an audit to access the Facepile there.

The tutorial below is shown in the administrator role with organizational permission as a manager in Hyperproof. If you are in another role in Hyperproof or have a different permission, you may not have access to some of these areas shown, or they may be greyed out.

In this video, we'll go over the user Facepile, where it is located, how to add users via the Facepile, and how to adjust permissions via the Facepile.

Click the arrows to learn more below:

Navigating the Facepile

  1. First, select the object you want to access the Facepile for. i.e. the audit.

  2. Click on the images of the members to open the member access dialog or click the + icon to add a user.

  3. Designate the object level permission, or change the object level permission in the member access dialog.

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.

Object roles and permissions define how users can interact with specific objects such as compliance programs, controls, audits, and related data. Roles determine whether users can manage, contribute to, or view an object.

Object roles and permissions are assigned when a user is added to an object or when their role needs to be updated to reflect their responsibilities. These assignments should be reviewed and adjusted as necessary to align with changing roles or organizational needs.

To participate in an object—programs, controls, labels, proof, audits, risks, or vendors—members of an organization (with the exception of Administrators) must be explicitly added to it and given a specific level of access.

Hyperproof has the following object-level roles.

Manager

Can manage and share content, manage object members, and manage object settings.

Contributor

Can share, add, and remove files from certain objects they are a member of.

Viewer

Can view files and information for certain objects they are a member of.

Important: whether a Manager, Contributor or Viewer, users must be added to an object before they can interact with it.

Combination of object roles

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.

Inherited access versus direct access

It’s important to note that some users may inherit permissions or direct access within an object.

All Hyperproof work items have a Facepile that allows for both inherited access and direct access to an object.

Facepile is Hyperproof's term for the area where users can view who has access to a particular object, e.g. a control. Depending on their permissions, users can add, remove, or change user roles. Work items can also be made private via the Facepile.

The difference between inherited access and direct access is:

  • Inherited access means that a user becomes a member of a work item by way of a parent object.

  • Direct access means that a user has been explicitly added to a work item, e.g. a user is specifically added to a request, but not the audit. Inherited access Users inherit access to work items via a parent object.

Click the arrows to learn more below:

Direct access

A user who has been specifically added to a work item is considered to have direct access to the object. When added, they receive the role of contributor. A user with sufficient permissions can change the new user's role to manager via the facepile.

Inherited access

Users inherit access to work items via a parent object. An example scenario might look like:

  • User X is a manager of control ID 1234.

  • An issue is created by another user and linked to control ID 1234.

  • Because User X is a member of the parent object—in this case the control—they gain contributor access to the issue.

To see how a user obtained inherited access, click the link next to the user’s email address.

Did this answer your question?