Skip to content
English
Customer portal
Contact us
  • There are no suggestions because the search field is empty.

03.03 Permission Reference

Reference catalog of every permission key SimpleRisk ships, grouped by domain — the Risk Management permissions, the Compliance permissions, the Governance permissions, the Asset/VM/IM/Assessments Extra permissions, and the visibility-control permissions that gate which records non-admin users can see.

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 (the permissions.key value used by check_permission() in code), their display label (the 'AbleToXxx' => 'Able to Xxx' value from simplerisk/languages/en/lang.en.php), 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

assessments

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

(admin)

  • Display Label: Allow Access to "Configure" Menu
  • What it gates: The Configure sidebar menu (admin-only)

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 mitigation form on /management/plan_mitigations.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 (in the Prioritize Planning surface)

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

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/UCF Extras)

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 "Configure" Menu
  • What it gates: The scanner-configuration 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 "Reporting" Menu
  • What it gates: The Incident Management reporting surface

im_configure

  • Display Label: Allow Access to Incident Management "Configure" Menu
  • What it gates: The Incident Management configuration UI

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_send_questionnaire

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

assessment_edit_template

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

Other Extra-specific permissions

The remaining Extras add their own permissions when activated. The pattern is the same: an _ 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/ .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) displays permissions in the permission_groups organization — bundles like "Risk Management Permissions," "Compliance Permissions," "Governance Permissions" — for ease of selection. The grouping is UI organization only; the underlying permission keys are what check_permission() reads at runtime.

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 = 
  
   ; -- 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 = 
   
    ); -- Admin override SELECT admin FROM user WHERE value = 
    
     ;

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

Related

Reference

  • Permission required: Server-side: MySQL access for direct catalog inspection. SimpleRisk-side: check_admin for the user-management UI.
  • API endpoint(s): GET /admin/users/all, GET /admin/users/enabled, GET /admin/users/disabled (admin-only — return users with their permissions and roles).
  • Implementing files: simplerisk/includes/permissions.php (the check_permission(), enforce_permission(), set_user_permissions(), get_permissions_of_user(), update_permissions() functions); simplerisk/languages/en/lang.en.php (the permission display labels); per-Extra: simplerisk/extras/ /includes/permissions.php (Extra-specific permission definitions).
  • Database tables: permissions (catalog with id, key, name, description, order); permission_to_user (direct grants, composite PK on permission_id+user_id); role, role_responsibilities (role-based grants); permission_groups, permission_to_permission_group (UI organization).
  • config_settings keys: None for the permission catalog itself. The visibility-control settings are held in the permissions table as the AllowXxx keys. The Separation Extra adds ~15 additional toggles (in the settings table) when activated.
  • External dependencies: None.