03.03 Permission Reference

Why this matters

Operators configuring user roles need to know what each permission key does — not "Able to Submit New Risks" as a label, but specifically which actions become available and which UI surfaces become visible when the permission is granted. The labels are descriptive but not always self-explanatory; this reference is the working catalog operators consult when designing roles or debugging "why can this user see this thing."

The catalog organizes permissions by domain. Within each domain, permissions are listed with their key, their display label as it appears in the user-management UI, and what they specifically gate. The ordering within a domain is roughly logical-progression order (read access first, then create, then modify, then approve/destructive).

The honest scope to know: this catalog reflects the current SimpleRisk release. New permissions appear with new releases as features ship; the release notes call out new permissions when they're added. After a Core upgrade, scan this reference (or the release notes' permission section) to see what new permissions exist and whether your role configurations should grant them. The full list also depends on which Extras are activated — the Extras add their own permissions when activated, and those are listed in the per-Extra sections below.

Reference content

Menu access permissions

These permissions gate the visibility of top-level sidebar menus. A user without the relevant menu permission doesn't see the corresponding menu at all.

`riskmanagement`

Display Label: Allow Access to "Risk Management" Menu
What it gates: The Risk Management sidebar menu and its sub-items

`compliance`

Display Label: Allow Access to "Compliance" Menu
What it gates: The Compliance sidebar menu and its sub-items

`governance`

Display Label: Allow Access to "Governance" Menu
What it gates: The Governance sidebar menu (Frameworks, Controls, Documentation, Document Exceptions)

`asset`

Display Label: Allow Access to "Asset Management" Menu
What it gates: The Asset Management sidebar menu, the Manage Assets page, and adding assets (see Asset Management permissions below for the rest)

`assessments`

Display Label: Allow Access to "Assessments" Menu
What it gates: The Assessments sidebar menu (Assessments Extra)

The admin Settings surface is reached from the Settings cog in the page header, not a sidebar menu. Three permissions gate access to that surface (the Settings Hub at /admin/index.php): admin sees every tile; vm_configure sees the Vulnerability Management Extra tile only; im_configure sees the Incident Management Extra tile only. Tile-level filtering happens server-side via the catalog's required_permissions field, so a user with just vm_configure opening the Settings cog lands in a Hub that shows them only the tiles they can use.

Risk Management permissions

`submit_risks`

Display Label: Able to Submit New Risks
What it gates: The Submit Risk form on /management/index.php; the submission API endpoint

`modify_risks`

Display Label: Able to Modify Risk Details
What it gates: Editing risk fields after submission; the reopen action

`close_risks`

Display Label: Able to Close Risks
What it gates: The Close Risk action on the risk detail view

`plan_mitigations`

Display Label: Able to Plan Mitigations
What it gates: The Plan Mitigation row action and Mitigation chip on /management/review_risk.php, and the per-risk mitigation tab

`accept_mitigations`

Display Label: Able to Accept Mitigations
What it gates: The Accept Mitigation second-line sign-off action

`review_insignificant`

Display Label: Able to Review Insignificant Risks
What it gates: Submitting reviews on Insignificant-level risks

`review_low`

Display Label: Able to Review Low Risks
What it gates: Submitting reviews on Low-level risks

`review_medium`

Display Label: Able to Review Medium Risks
What it gates: Submitting reviews on Medium-level risks

`review_high`

Display Label: Able to Review High Risks
What it gates: Submitting reviews on High-level risks

`review_veryhigh`

Display Label: Able to Review Very High Risks
What it gates: Submitting reviews on Very High-level risks

The five level-gated review permissions (review_insignificant through review_veryhigh) are what implement the level-based review-permission model documented in Reviewing and Approving Risks. A reviewer needs the permission matching the risk's calculated level.

Compliance permissions

`define_tests`

Display Label: Able to Define Tests
What it gates: Creating and editing test definitions on the Define Tests tab

`edit_tests`

Display Label: Able to Edit Tests
What it gates: Editing existing test definitions

`delete_tests`

Display Label: Able to Delete Tests
What it gates: Deleting test definitions

`initiate_audits`

Display Label: Able to Initiate Audits
What it gates: Creating new audit instances (manually or batch via the audit-initiation page)

`modify_audits`

Display Label: Able to Modify Audits
What it gates: Submitting test results, editing in-progress audits

`reopen_audits`

Display Label: Able to Reopen Audits
What it gates: Reopening closed audits

`delete_audits`

Display Label: Able to Delete Audits
What it gates: Removing audit records

`add_projects`

Display Label: Able to Add Projects
What it gates: Creating projects (on the Plan Projects page)

`manage_projects`

Display Label: Able to Manage Projects
What it gates: Reordering projects, changing project status

`delete_projects`

Display Label: Able to Delete Projects
What it gates: Deleting projects

Asset Management permissions

The asset menu-access permission above opens the Manage Assets page and lets a user add assets. Everything else on that page has its own permission, and the page shows a user only the actions they hold.

`asset_edit`

Display Label: Able to Edit Assets
What it gates: Editing an asset's fields, and the matching API update endpoints

`asset_delete`

Display Label: Able to Delete Assets
What it gates: Deleting assets, one at a time or in bulk, and the matching API endpoints

`asset_verify`

Display Label: Able to Verify Assets
What it gates: Verifying assets and marking them unverified, the Verification card when editing an asset, and having the assets the user creates start out verified

`asset_discovery`

Display Label: Able to Run Asset Discovery
What it gates: Starting, listing, and canceling network discovery runs

`asset_group_create`

Display Label: Able to Create Asset Groups
What it gates: Creating asset groups

`asset_group_edit`

Display Label: Able to Edit Asset Groups
What it gates: Renaming a group and adding or removing its members

`asset_group_delete`

Display Label: Able to Delete Asset Groups
What it gates: Deleting asset groups, one at a time or several at once from the Asset Groups tab (the member assets are never deleted)

Two behaviors to plan for. First, the upgrade that introduced these permissions granted all seven to every user and role that held asset at the time, so nothing changes for existing accounts until you narrow them; administrators have them automatically. Second, verification depends on asset_verify: assets created by a user without it start out unverified, including assets that user creates through a risk form or a discovery run. Make sure at least one role holds it, or the unverified list can only grow. The setting Automatically verify new Assets created through the Asset Selector widget (Settings cog → Settings Hub → Preferences tile → Asset Management tab) makes every new asset verified regardless of who creates it.

One cross-menu dependency: choosing the controls in an asset's Mapped Controls field reads the control catalog, so it also needs governance. A user with asset_edit but not governance sees the mapping read-only in the asset window, and saving their other changes leaves it as it was.

Governance permissions

For frameworks and controls:

`add_new_frameworks`

Display Label: Able to Add New Frameworks
What it gates: Creating new frameworks (manual create, GitHub install, or via the SCF Extra)

`modify_frameworks`

Display Label: Able to Modify Existing Frameworks
What it gates: Editing framework metadata

`delete_frameworks`

Display Label: Able to Delete Existing Frameworks
What it gates: Deleting frameworks (cascades to controls and test history)

`add_new_controls`

Display Label: Able to Add New Controls
What it gates: Creating new controls within frameworks

`modify_controls`

Display Label: Able to Modify Existing Controls
What it gates: Editing controls (including the cross-framework mapping UI on the control edit modal)

`delete_controls`

Display Label: Able to Delete Existing Controls
What it gates: Deleting controls

For documentation:

`add_documentation`

Display Label: Able to Add Documentation
What it gates: Creating documents in the document library

`modify_documentation`

Display Label: Able to Modify Documentation
What it gates: Editing document fields

`delete_documentation`

Display Label: Able to Delete Documentation
What it gates: Deleting documents

For exceptions:

`view_exception`

Display Label: Able to View Exceptions
What it gates: Reading the document-exceptions page

`create_exception`

Display Label: Able to Create Exceptions
What it gates: Creating new exceptions

`update_exception`

Display Label: Able to Update Exceptions
What it gates: Editing existing exceptions (resets approval per the load-bearing rule documented in Exceptions Management)

`delete_exception`

Display Label: Able to Delete Exceptions
What it gates: Deleting exceptions

`approve_exception`

Display Label: Able to Approve Exceptions
What it gates: The approval action on the exception form

For comments:

`comment_riskmanagement`

Display Label: Able to Comment Risk Management
What it gates: Commenting on risks

`comment_compliance`

Display Label: Able to Comment Compliance
What it gates: Commenting on compliance entities

Visibility permissions

These don't gate actions — they gate which records a user can see. They work in concert with team-based segregation (see Team-Based Segregation) and with the Separation Extra (see Separation of Duties).

For risks:

`AllowAllUsersToSeeRisksNotAssignedToTeam`

Display Label: Allow all users to see risks not assigned to a team
What it gates: Visibility of risks with no team assignment to users who'd otherwise be filtered out

For documents:

`AllowAllUsersToSeeDocumentsNotAssignedToTeam`

Display Label: Allow all users to see documents not assigned to a team
What it gates: Visibility of unassigned-team documents

`AllowAllUsersToSeeAllDocuments`

Display Label: Allow All Users to See All Documents
What it gates: Bypass team filtering for documents (everyone sees everything)

For assets:

`AllowAllUsersToSeeAssetsNotAssignedToTeam`

Display Label: Allow all users to see assets not assigned to a team
What it gates: Visibility of unassigned-team assets

For test/audit details (which roles can see test details for controls they're not directly testing):

`AllowControlOwnerToSeeTestAndAuditDetails`

Display Label: Allow Control Owner to see Test/Audit details
What it gates: Control owners see tests/audits on their controls

`AllowTesterToSeeTestAndAuditDetails`

Display Label: Allow Tester to see Test/Audit details
What it gates: Designated testers see test/audit details

`AllowAssignedTeamsMembersToSeeTestAndAuditDetails`

Display Label: Allow members of Assigned Teams to see Test/Audit details
What it gates: Team members see tests/audits for their team's controls

`AllowStakeholdersToSeeTestAndAuditDetails`

Display Label: Allow Stakeholders to see Test/Audit details
What it gates: Additional stakeholders see test/audit details

`AllowEveryoneToSeeTestAndAuditDetails`

Display Label: Allow Everyone to see Test/Audit details
What it gates: Bypass — everyone sees test/audit details

Vulnerability Management Extra permissions

Activated by the Vulnerability Management Extra:

`vm_vulnerabilities`

Display Label: Allow Access to Vulnerability Management "Vulnerabilities" Menu
What it gates: The Vulnerabilities triage queue

`vm_configure`

Display Label: Allow Access to Vulnerability Management Settings
What it gates: The Vulnerability Management tile in the Settings Hub (Settings cog → /admin/index.php). The tile leads to admin/vulnmgmt.php, which inlines the scanner configuration UI (formerly the standalone vulnerabilities/configure.php page).

`vm_triage_approve`

Display Label: Able to Approve Vulnerability Triage to Risk
What it gates: The Approve action on triage queue findings

`vm_triage_reject`

Display Label: Able to Reject Vulnerability Triage to Risk
What it gates: The Reject action on triage queue findings

Incident Management Extra permissions

Activated by the Incident Management Extra (15 permissions):

`im_incidents`

Display Label: Allow Access to Incident Management "Incidents" Menu
What it gates: All incident sub-menus and views

`im_submit_incidents`

Display Label: Able to Submit New Incidents
What it gates: The Submit An Incident form

`im_edit_incidents`

Display Label: Able to Modify Existing Incidents
What it gates: Editing incident details, status transitions

`im_delete_incidents`

Display Label: Able to Delete Incidents
What it gates: Deleting incident records

`im_select_preparation`

Display Label: Able to Select Incident Preparation Items
What it gates: Marking preparation items complete

`im_edit_playbook`

Display Label: Able to Select Incident Playbook
What it gates: Assigning playbooks to incidents, editing playbooks

`im_select_response`

Display Label: Able to Select Incident Response Items
What it gates: Checking off action steps in Containment/Eradication/Recovery

`im_add_evidence`

Display Label: Able to Add Incident Evidence
What it gates: Uploading evidence files to incidents

`im_delete_evidence`

Display Label: Able to Delete Incident Evidence
What it gates: Removing evidence files

`im_add_notes`

Display Label: Able to Add Incident Notes
What it gates: Adding notes to incidents

`im_delete_notes`

Display Label: Able to Delete Incident Notes
What it gates: Removing notes

`im_add_lessons`

Display Label: Able to Add Lessons Learned to Incident
What it gates: Attaching lessons-learned entries to incidents

`im_dismiss_lessons`

Display Label: Able to Dismiss Lessons Learned from Incident
What it gates: Dismissing incidents from the Lessons Learned queue

`im_reporting`

Display Label: Allow Access to Incident Management Reports and Dashboards
What it gates: The Incident Management reports and the Incident Dashboard inside the core Reports and Dashboards Hub

`im_configure`

Display Label: Allow Access to Incident Management Settings
What it gates: The Incident Management tile in the Settings Hub (Settings cog → /admin/index.php). The tile leads to admin/incidentmanagement.php, which renders the IM admin surface as four tabs — Settings, Add and Remove Values, Playbooks, and Notifications (the Notifications tab only appears when the Notification Extra is also active).

Assessments Extra permissions

Activated by the Assessments Extra:

`assessments`

Display Label: Allow Access to "Assessments" Menu
What it gates: All Assessments sub-menus

`assessment_add_contact`

Display Label: Able to Add Assessment Contacts
What it gates: Creating new external contacts

`assessment_edit_contact`

Display Label: Able to Edit Assessment Contacts
What it gates: Editing existing contacts

`assessment_delete_contact`

Display Label: Able to Delete Assessment Contacts
What it gates: Deleting contacts

`assessment_add_question`

Display Label: Able to Add Assessment Questions
What it gates: The "Add new question" button on Questionnaire Questions

`assessment_edit_question`

Display Label: Able to Edit Assessment Questions
What it gates: The Edit button on Questionnaire Questions

`assessment_delete_question`

Display Label: Able to Delete Assessment Questions
What it gates: The Delete button on Questionnaire Questions

`assessment_add_template`

Display Label: Able to Add Questionnaire Templates
What it gates: The Add and Copy buttons on Questionnaire Templates

`assessment_edit_template`

Display Label: Able to Edit Questionnaire Templates
What it gates: Editing templates and the question-to-control mapping

`assessment_delete_template`

Display Label: Able to Delete Questionnaire Templates
What it gates: The Delete button on Questionnaire Templates

`assessment_add_questionnaire`

Display Label: Able to Add Questionnaires
What it gates: The Add and Copy buttons on Questionnaires

`assessment_edit_questionnaire`

Display Label: Able to Edit Questionnaires
What it gates: The Edit button on Questionnaires

`assessment_delete_questionnaire`

Display Label: Able to Delete Questionnaires
What it gates: The Delete button on Questionnaires

`assessment_send_questionnaire`

Display Label: Able to Send Questionnaires
What it gates: The Save & Send action on the questionnaire form

`assessment_view_results`

Display Label: Able to View Questionnaire Results
What it gates: The Questionnaire Results page (/assessments/questionnaire_results.php); users without this permission see a "no permission" notice instead of the results table

`assessment_decide_results`

Display Label: Able to Approve, Reject, or Not Approve Questionnaire Results
What it gates: The Approve, Reject, and Not Approved action buttons on a result detail view, and the corresponding /result/approve, /result/reject, /result/notapproved API endpoints

`assessment_reopen_results`

Display Label: Able to Reopen Questionnaire Results
What it gates: The Reopen button on a decided result, and the /result/reopen API endpoint. Reopening an approved result also requires assessment_decide_results

Other Extra-specific permissions

The remaining Extras add their own permissions when activated. The pattern is the same: an {extra-prefix}_{action} permission key that gates the relevant UI and API surface. For the full inventory of an Extra's permissions, consult the Extra's own admin page (typically /admin/{extra-name}.php) which lists the registered permissions.

Configuration permissions

`AllowedFileTypes`

Display Label: Allowed File Types
What it gates: Configuration of allowed file types for uploads

How permissions appear in the user-management UI

The user-management UI (covered in Managing Users, Teams, and Roles) bundles permissions into groups — "Risk Management Permissions," "Compliance Permissions," "Governance Permissions" — to make them easier to pick through. Those groups are a convenience for selection only. What actually gates access is the individual permission.

Programmatic access

To inspect a user's permissions:

-- Direct grants
SELECT p.key, p.name FROM permission_to_user ptu
JOIN permissions p ON p.id = ptu.permission_id
WHERE ptu.user_id = {user_id};

-- Role-based grants
SELECT p.key, p.name FROM role_responsibilities rr
JOIN permissions p ON p.id = rr.permission_id
WHERE rr.role_id = (SELECT role_id FROM user WHERE value = {user_id});

-- Admin override
SELECT admin FROM user WHERE value = {user_id};

The v2 API exposes user-with-permissions queries via GET /admin/users/all, GET /admin/users/enabled, and GET /admin/users/disabled (admin-only).

Managing Users, Teams, and Roles
The Permission Model
Organizational Hierarchy
Separation of Duties
Team-Based Segregation
Reviewing and Approving Risks (for the level-gated review permissions in operation)
Exceptions Management (for the exception-permission gating)
The Incident Management Extra (for the IM permissions in operation)