Granting permissions to iGRC
Learn how to grant permissions to iGRC registers
iGRC adds four registers to your team: Tests, Controls, Files and Tasks and includes Hailey-assisted mapping between the items in them. By default, only administrators and advisors will have access to them.
If you have permission to manage roles, you can update your custom roles so that those who need to work in the registers, for example, the people collecting evidence, owning controls, and reviewing results, can be granted the necessary permissions.
The iGRC permissions are fine-grained and are granted per register. Decide before you begin which roles will collect evidence, review it, and configure the registers.
Table of Contents
Granting a role access to the iGRC registers
- Navigate to Administration → Roles
- Select the role you wish to change, then select Edit. To build a new role, select New Role.
- Open the Permissions tab
- Expand General → Register. Each register appears as a branch named after the register itself: Tasks, Files, Controls, Tests.
- Tick the register name to give the role access to that register, then tick the child permissions the role needs.
- Select Save
Ticking the register name alone gives read access to the register and its items.
Permissions
These permissions appear under each of the four iGRC registers:
| Permission | What it allows |
|---|---|
| (the register name) |
View-only access to the register and open its items. Pre-requisite for permission below to have any effect. |
| Create | Allows users to create new items in the register |
| Edit | Allows users to edit existing items in the register |
| Edit → Workflow stage transition | Allows users to move register items from one workflow to another if workflow stages are enabled for the register |
| Delete | Allows users to delete existing items in the register |
| Settings |
Allows users to access and edit the settings page of the register including using the workflow toggle. Allows users to change the register's own configuration, i.e., custom fields, stages, and register-level settings |
| View all | Allows users to view all items in the register |
| Comments | Allows users to view the comments of register items |
| Comments → Add | Allows users to add or import comments for register items |
| Attachments | Allows users to view the list of attachments under register items |
| Attachments → Preview attachments | Allows users to preview attachments of register items without being able to download them |
| Attachments → Download attachments | Allows users to download attachments of register items |
| Attachments → Upload attachments | Allows users to upload attachments against register items |
| Attachments → Delete attachments | Allows users to delete attachements against register items |
| Create requirement based assessments | Start a requirement-based assessment from an item. Relevant on the Controls register. |
| Access members | Allows users to see the access members field for each item they can view in the register |
| Access members → Manage access members | Allows users to edit the access members field for each item they can view in the register i.e. add and remove other users |
These permissions are specific to the listed register:
| Register | Permission | What it allows |
|---|---|---|
| Test | Test result → Create / Edit / Delete | Record and manage test results against a test |
| Task | Task log → Create / Edit / Delete | Create and manage task logs |
| Control, Files | Workflow stages → Create / Edit / Delete, Stage access → Manage stage access, Stage requirements → Manage stage requirements | Build and manage the register's workflow stages, and control who can act at each stage |
Differences between custom registers and iGRC registers
The custom registers used for iGRC have some distinct permission settings that may be worth noting.
-
The four iGRC registers have no Tasks branch. Unlike some other registers, items in the Tests, Controls, Files and Tasks registers do not carry their own Tasks tab, so there is no Tasks permission to grant. Work is tracked through the Task register itself.
-
.Test and Task have no Workflow stages permission. Creating, editing and Deleting Workflow stages is managed by 6clicks and cannot be edited, Items in both registers still move between stages. The permission, Edit → Workflow stage transition, is granted separately and is available in all four registers.
Suggested starting point for granting permissions
The following combinations might be a place to start. Adjust them as needed.
| Responsibility | Registers | Permissions |
|---|---|---|
| Evidence collector uploads evidence against tests and tasks | Tests, Tasks, Files | The register name, Edit, Comments → Add, Attachments and all four attachment children |
| Control owner owns controls and reviews test outcomes | Controls, Tests | The register name, Create, Edit, View all, Comments → Add, Attachments, Test result → Create / Edit on Test |
| Compliance reviewer reads everything, changes nothing | All four | The register name, View all, Comments, Attachments → Preview attachments / Download attachments |
| Register administrator configures the registers | All four | Everything, including Settings on all four and Workflow stages on Control and Files |
Note: Allow the Settings and Delete permissions only after careful consideration.
Settings allows users assigned to a role to change the register's custom fields and stages for everyone. Delete removes items permanently. Both permissions should be restricted to a small number of administrators.
Hailey-assisted mappings between register items
Hailey suggests links between items in different registers, e.g., a control to a test, a test to a task. You may accept or reject each suggestion.
Suggestions are shown only to users who can edit the register the item belongs to. A user with read access alone does not see them; rather than presenting suggestions nobody can action, the panel stays out of the way.
If someone should be working through Hailey's suggestions, grant them Edit on that register. Nothing else needs to be turned on.
Advisors working in spokes
If you are an advisor managing client spokes, iGRC permissions are set inside each spoke, against that spoke's own roles and its own registers. Register permissions are not shared between spokes — each spoke's registers are its own so there is no single change that grants iGRC access across all of them at once.
Troubleshooting
| Symptom | Cause and fix |
|---|---|
| A user has the role but cannot see a register | Verify that the register name itself is ticked, not only its children. The children permissions do nothing on their own. Then check the user has not been individually denied it under Administration → Users → Permissions. |
| A user sees the register but only some items | They are missing View all, which is what widens the view beyond the items with which they are associated |
| A user can open an item but not upload evidence | Attachments → Upload attachments has not been granted |
| A user sees no Hailey mapping suggestions at all | They have read access to the register but not Edit. Suggestions are only shown to users who can act on them. |
| Workflow stages is missing on the Test or Task register | This is expected behavior. Workflow stages on these registers are managed by 6clicks and cannot be edited. Check the Controls and Files registers, where the permission does appear. |
| Access members is missing from a register | Item-level access members is a separate capability, and it isn't on for every subscription. If it isn't in the tree, a role change won't bring it back. |
| Register names appear in English on a translated interface | This is expected behavior. The iGRC register names, field labels and stage names are English in every region. |
For related information, review the following articles: