Roles and permissions¶
The platform distinguishes two independent dimensions of authorisation:
- Platform permissions: whether an account is a User or an Admin. Maintained on the Users tab of Administration.
- Company role: whether an account is a User or a Manager within a given company. Maintained on the Users tab of Companies.
An account can be a manager in one company and a regular user in another. Platform administrator permissions apply everywhere.
Project management permissions also depend on the user's relationship to the project. The user who creates a project is its project manager. This is separate from the company Manager role: a regular user can manage the settings, monitoring, and access of a project they created.
Scope of this matrix
The table below reflects the role model of the platform: which functions each role is intended to access. Where a deployment has been configured differently, the interface is authoritative: a function that a role may not use is either not shown or cannot be selected. Confirm the matrix against your own deployment before relying on it for an access review.
Overview¶
| Function | User | Manager | Admin |
|---|---|---|---|
| Open a project they have access to | Yes | Yes | Yes |
| Leave a project available exclusively through direct access | Yes, unless they manage it | Yes, unless they manage it through an associated company | No; administrators manage every project |
| Create a project | Yes | Yes | Yes |
| Edit the scope, assess discovery findings | Yes | Yes | Yes |
| Change project settings and monitoring | Only as project manager (they created the project) | Yes | Yes |
| Delete their own project | Yes | Yes | Yes |
| Grant other users access to a project | Only as project manager (they created the project) | Yes | Yes |
| Export project data | Yes | Yes | Yes |
| Manage their own profile, password, 2FA, API keys | Yes | Yes | Yes |
| View company data, plans, and quota consumption | Yes | Yes | Yes |
| Amend company data | No | Yes | Yes |
| Invite and remove company members | No | Yes | Yes |
| Promote a member to manager | No | Yes | Yes |
| Create and maintain presets | No | Yes | Yes |
| See every project on the platform | No | No | Yes |
| Change the owner of a project | No | No | Yes |
| Create, edit, suspend, and delete user accounts | No | No | Yes |
| Grant administrator permissions | No | No | Yes |
| Approve registration requests | No | No | Yes |
| Create companies and assign plans | No | No | Yes |
| Create and maintain template plans | No | No | Yes |
| Configure darknet anonymisation for an account | No | No | Yes |
What each role is for¶
User. Works inside the projects they have access to. This is the correct role for an analyst: the full result set and the full assessment workflow, without the ability to change commercial or membership settings.
Manager. A user who additionally administers one company: its data, its members, and its presets. A manager does not gain access to projects they have not been given access to; the role governs the company, not its results.
Admin. Administers the platform. An administrator sees every project of every company and can reassign ownership, create accounts, and define the quota that companies receive. Grant this permission to as few accounts as possible, and enable two-factor authentication on each of them; see Preferences.
Practical consequences¶
| Situation | Correct approach |
|---|---|
| A colleague needs to work on one project | Grant access on the Access tab of the project settings. Do not raise their role. |
| A colleague needs to administer the team | Promote them to Manager on the Users tab of Companies. |
| An employee leaves | An administrator transfers their projects with Change project owner, then sets their Status to Inactive. |
| Someone needs to see darknet severity but not the personal data | An administrator sets Darknet Anonymization to Active for that account. |
| An integration needs programmatic access | Issue a Read only API key in Preferences rather than sharing an account. |