13.04 Default Roles and Permissions

Why this is a reference article

This article catalogs the default roles SimpleRisk ships with and the typical permissions they grant. For the exact mappings on your install (which may have been customized), check the role management UI at Configure → User Management → Roles or query the database directly:

SELECT r.name AS role, p.name AS permission
FROM role r
JOIN role_responsibilities rr ON rr.role_id = r.value
JOIN permissions p ON p.value = rr.permission_id
ORDER BY r.name, p.name;

The default roles are starting points; most programs customize them or define new roles to match their operational structure. The catalog below is for orientation, not as the authoritative current state.

The default roles

SimpleRisk's default role catalog typically includes:

Administrator

The system administrator role. This is separate from the user.admin = 1 flag (which is the global admin override). The Administrator role grants admin-level permissions through the standard role-grant mechanism.

Typical permissions: nearly all permissions in the catalog, including check_admin, user management, system configuration, all entity CRUD.

Use for: operators of the SimpleRisk install. Limit to the small group of users genuinely operating the platform.

User

The default role assigned to new users when no specific role is chosen. Minimal permissions — typically just enough to view their assigned risks and submit risks.

Typical permissions: submit_risks, view permissions for own-team risks, basic profile management.

Use for: users who interact with SimpleRisk occasionally — submitting risks, reviewing risks they own, but not managing the broader program.

Risk Manager

The role for users who manage the risk register day-to-day. Broader risk-related permissions but not full administrator access.

Typical permissions: submit_risks, modify_risks, close_risks, accept_mitigation, review_high, review_medium, review_low, add_new_frameworks, etc.

Use for: program leads, risk managers, GRC team members.

Risk Submitter

A focused role for users who only submit risks (don't review, don't mitigate, don't manage frameworks).

Typical permissions: submit_risks, view permissions for risks they've submitted.

Use for: business users in non-GRC roles who occasionally submit risks for the program to evaluate.

Risk Reviewer

A focused role for users who review submitted risks but don't manage them otherwise.

Typical permissions: review_high, review_medium, review_low, view permissions.

Use for: stakeholders involved in risk review approvals.

Risk Mitigator

A focused role for users who plan and execute mitigations.

Typical permissions: plan_mitigations, view permissions, mitigation update permissions.

Use for: control owners, security engineers, IT operators implementing mitigations.

Compliance Manager

The role for users managing compliance frameworks, controls, and audits.

Typical permissions: governance, add_new_frameworks, add_new_controls, audit-related permissions, document management permissions.

Use for: compliance team members, framework owners, audit coordinators.

Auditor

A read-mostly role for auditors (internal or external) accessing the install.

Typical permissions: view permissions for the entities being audited; comment permissions; no modify or delete.

Use for: auditors who need to verify controls and findings without modifying the register.

Asset Manager

The role for users managing the asset inventory.

Typical permissions: add_new_assets, modify_assets, asset-related view permissions, asset-team management.

Use for: IT asset managers, configuration management leads.

Common patterns

Customizing default roles

Edit the role's permission grants via Configure → User Management → Roles → [role] → Permissions. The change applies to all users with that role; permission changes take effect on each user's next login (the session cache reloads — see The Permission Model).

Defining new roles

Common patterns for new roles:

Department-specific roles — "Engineering Risk Manager" with the same permissions as Risk Manager but constrained to engineering-relevant frameworks via team-segregation.
Read-only executive role — view-everything permissions; no modify; for executives who consume reports.
API-integration role — minimal scope tailored to a specific integration's needs (e.g., "API CI" for the CI/CD pipeline that closes risks).

Avoiding role explosion

A program with 20 nuanced roles is hard to administer; most operators end up granting "the closest role" rather than maintaining the nuance. Aim for 5-8 named roles plus per-user direct grants for edge cases.

Permissions catalog (high-level groupings)

The full permissions catalog is in Permission Reference. High-level groupings the default roles draw from:

Risk lifecycle: submit_risks, modify_risks, close_risks, delete_risks, accept_mitigation, plan_mitigations.
Review: review_high, review_medium, review_low, review_insignificant.
Governance: governance, add_new_frameworks, add_new_controls, manage_documents, manage_exceptions.
Compliance: add_audit, modify_audit, audit_compliance, view_compliance.
Assets: add_new_assets, modify_assets, delete_assets.
Users: manage_users, assign_user_to_team (the latter may be admin-only).
Configuration: check_admin (master admin gate); various Extra-specific configuration permissions.
API: implicit — every user with api_keys (or whatever the install uses for API access enablement) can have an API key.

Querying the actual mappings

For the install's current role-to-permission mappings:

-- All roles with their permission counts
SELECT r.name, COUNT(rr.permission_id) AS perm_count
FROM role r
LEFT JOIN role_responsibilities rr ON rr.role_id = r.value
GROUP BY r.name
ORDER BY perm_count DESC;

-- Specific role's permissions
SELECT p.key, p.name
FROM role r
JOIN role_responsibilities rr ON rr.role_id = r.value
JOIN permissions p ON p.value = rr.permission_id
WHERE r.name = 'Risk Manager'
ORDER BY p.name;

-- Users with each role
SELECT r.name AS role, COUNT(u.id) AS user_count
FROM role r
LEFT JOIN user u ON u.role_id = r.value
GROUP BY r.name
ORDER BY user_count DESC;

These queries show what the install actually has, not what the defaults would suggest.

Common pitfalls

A handful of patterns recur with default roles.

Granting Administrator to "make permissions easy." It bypasses every check; the user has admin-level access. Use the User role with appropriate per-user direct grants instead.
Modifying the User role to add many permissions. New users get those permissions automatically; the role bloats over time. Consider defining a new role for the broader permission set.
Not re-evaluating role definitions after Core upgrades. New permissions ship in upgrades; existing roles don't auto-include them. Check role definitions after each upgrade.
Confusing the Administrator role with the user.admin = 1 flag. The role is one way to grant admin permissions; the flag is a global override. Both produce admin behavior; the flag is broader.
Letting role definitions diverge from the program's documented roles. If your program has documented roles ("Compliance Lead," "Security Engineer"), align the SimpleRisk roles to match — name them the same, grant the same permissions.
Defining roles without periodic review. Role-to-permission mappings drift. Schedule annual review.
Granting roles based on requests rather than design. "Bob asked for X permission so I added it to his role" produces sprawl. Design the role; grant the role; if Bob needs an exception, use direct grants.
Treating roles as immutable. Roles evolve with the program; refactor periodically (with care for downstream effects on existing users).