---
title: 03.01 Managing Users, Teams, and Roles
description: Add, edit, deactivate, and delete users; create teams and assign membership; create roles and bind permissions; understand how the three layers compose…
---
[Skip to content](https://support.simplerisk.com/kb/03-01-managing-users-teams-and-roles#main-content)
English
Show submenu for translations
[Customer portal](https://support.simplerisk.com/tickets?hsLang=en)
[](https://www.simplerisk.com/)
Open main navigation
Close main navigation
- English
Show submenu for translations
- [Customer portal](https://support.simplerisk.com/tickets)
- [Contact us](https://www.simplerisk.com/about-us/contact-us)
[Contact us](https://www.simplerisk.com/about-us/contact-us)
How can we help you?
- There are no suggestions because the search field is empty.
1. [SimpleRisk Knowledge Base](https://support.simplerisk.com/kb?hsLang=en)
2. [Administrator Guide](https://support.simplerisk.com/kb/administrator-guide?hsLang=en)
3. [03 Users and Permissions](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#03-users-and-permissions)
# 03.01 Managing Users, Teams, and Roles
## Add, edit, deactivate, and delete users; create teams and assign membership; create roles and bind permissions; understand how the three layers compose to control what each person can see and do.
## Why this matters
SimpleRisk's access model is three layers. Users are the people who log in. Teams group users for ownership and reporting. Roles are reusable bundles of permissions assigned to users. The three are independent: identity doesn't change with role, and team membership doesn't grant permissions. Admins who collapse the layers — putting permissions on teams, or using roles as departmental groupings — end up rebuilding the access model six months later.
The discipline maps onto NIST SP 800-53's access-control family. AC-2 *Account Management* governs the user lifecycle. AC-3 *Access Enforcement* is what role and permission bindings enforce at every page render. AC-6 *Least Privilege* is the test you apply when deciding which permissions a role gets. The three admin pages (**User Management**, **Team Management**, **Role Management**) each map to one of those concerns.
## Users
A user record is the prerequisite for everything else: nothing to attach a role to and nothing to put on a team without one. A user carries a username (the login) and an administrator switch (on = superuser, off = permissions come from their role and any per-user changes). The page is the Settings Hub's **User Management** tile (Settings cog, top-right of any page → **User Management**), gated by the `admin` permission.
The page has three tabs: **Users**, **User Settings** (the password and lockout policy, covered in [Local Authentication and Password Policies](https://support.simplerisk.com/kb/04-01-local-authentication-and-password-policies?hsLang=en)), and **User Reports** (who holds which permission, role, or team). Everything about one person lives on the **Users** tab.
### Finding and selecting a user
The **Users** tab is a list on the left and the selected user's form on the right. Search the list with **Search users**, and narrow it with the **All**, **Enabled**, and **Disabled** chips. The page opens on **Enabled**, so a disabled leaver doesn't clutter the list; if there are no enabled users it falls back to **All**. Click a name to open that person's form. The address updates, so a link to a selected user is shareable with another admin.
Each row carries a few small icons: a shield for administrators, a padlock for locked accounts, an icon to disable or enable the account, and a trash can to delete it. The old standalone **View Details for User** page is gone. Any bookmark to it redirects to the same user on this page.
### Adding a user
Click **New user** above the list. The form opens with an **Account** card, a **Teams and sign-in** card, and a **Role and responsibilities** card. Most installs only use the **SimpleRisk** account type; the **LDAP** and **SAML** options only appear when the [Authentication Extra](https://support.simplerisk.com/kb/04-03-the-authentication-extra-overview?hsLang=en) is active and mean authentication is delegated to an IdP rather than a local password.
The **Account** card:
- **Type** — `SimpleRisk`, `LDAP`, or `SAML`. Pick the one matching how the user will authenticate.
- **Full Name** — display name, max 50 characters. Surfaces in dropdowns, audit-trail entries, and notifications.
- **E-mail Address** — must be unique and must validate as an email. Used for password resets and notifications.
- **Username** — the login. Must be unique. The `Use Case Sensitive Validation of Username` setting on the **User Settings** tab controls whether `jsmith` and `JSmith` are treated as the same user; default is on.
- **Password** / **Repeat Password** — only meaningful for SimpleRisk-typed users. Validated against the password policy on **User Settings**.
- **Language** — the user's interface language. Users who don't pick one get the system default.
- **Manager** — single-user picker; used by review-routing when the direct owner is unavailable.
The **Teams and sign-in** card holds the **Team(s)** multi-select (see *Teams* below for what membership does), **Require password change on login** (the next sign-in prompts for a new password, handy for temporary credentials), and **Multi-Factor Authentication**. If `mfa_required` is set system-wide, the MFA switch is on and read-only.
Click **Create user** to save. SimpleRisk shows: *A new user with username "`{username}`" was added successfully.* and opens the new user. Username and email collisions are reported with specific error messages.
### Role, responsibilities, and the Administrator switch
The **Role and responsibilities** card is where most of the thinking happens, so it's worth slowing down on how it behaves.
A **role** is the starting point. Pick one in the **Role** field and the permission checkboxes below it fill in with what that role grants. From there the checkboxes stay editable: tick one the role doesn't include, or clear one it does, and the change belongs to this user alone. Nothing happens to the role itself.
SimpleRisk keeps track of the difference so you don't have to. Under the **Role** field, a summary line reads either *Matches the "{role}" role.* or *Compared with the "{role}" role: {n} added, {n} removed.* Each individually changed permission carries an **Added** or **Removed** tag, and removed ones are struck through. **Reset to role** discards the user's changes and goes back to exactly what the role grants. Changing the role replaces the checkboxes with the new role's, so reach for **Reset to role** or change the role *before* you fine-tune.
**Administrator** isn't a role you pick. It's a switch at the top of the card, and the **Role** list doesn't offer the Administrator role at all. Turn it on and SimpleRisk does three things at once: every permission is checked and locked, every team is selected and locked (administrators belong to every team automatically), and the **Role** field is disabled. A note under the switch says why: *Responsibilities and teams are locked because this user is an administrator.* Turn the switch off again and the form returns to what the user had before you flipped it. A user who was already an administrator comes back with no role chosen, so pick one before you save.
Two guardrails apply. An administrator editing their own account can't turn their own switch off, and SimpleRisk shows *Admin users are unable to remove their own admin permission or lock themselves out.* So demoting an admin takes a second admin. And because the switch gives away everything, think of it as the "break glass" setting rather than a convenient way to skip role design.
### Importing users in bulk
With the Import/Export Extra active, the **Import-Export Extra** tile in the Settings Hub creates or updates many users from one spreadsheet. On the **Import** tab, choose **Import Users** in the **Select** list, upload a CSV or Excel file, map its columns (Username, Full Name, and a valid E-mail Address are required; Role, Teams, Permissions and the rest are optional), and click **Import**.
The import runs in the background, so a large file doesn't hold up the page or run into a load balancer's timeout. The page shows a progress bar and, when it finishes, how many users were created and updated and which rows were skipped and why (a row with a blank username or full name, or an invalid email address, is skipped; the rest still import). You can leave the page while it runs and come back to it to see the result.
New users get a generated temporary password and must change it at first sign-in. For safety SimpleRisk never keeps anything that can show those passwords again. When the import is queued, your browser is given a one-time key; the passwords are stored sealed to it and only that key opens them. When the import finishes, **Show temporary passwords** uses the key to display them **once**, then erases them. If the import stops early, the passwords of the users it did create can be shown the same way. Copy them and hand each to its user securely. They are only available in the browser tab that started the import: if you close the tab first, or sign in from another browser, they can no longer be shown, and unrevealed passwords are erased after two hours in any case. The users still exist, and you can set a new password for each by editing the user.
When a Role is mapped and no Permissions column is, a new user receives that role's permissions. A Permissions or Admin column, when mapped, takes precedence over the role.
### Editing, unlocking, and resetting a user
Select the user in the list and edit any field in the form, then click **Update**. Passwords aren't edited here. Use the reset actions in the form header instead:
- **Reset password** — opens a confirmation. Choose **Send reset email** and SimpleRisk emails the user a reset link. A reset can be requested once every 10 minutes; a second attempt inside that window is refused with a message saying so. If outbound email isn't working, the page tells you to check the email settings.
- **Reset MFA** — removes the user's current multi-factor authentication setup after you confirm, so they can enroll a new device. This is the lost-phone recovery path.
- **Unlock** — shown, along with an **Account Locked Out** badge, only while the account is locked, either by the failed-login policy or until the user completes a password reset. Click it to let the user sign in again without resetting their password. Unlock doesn't save anything else on the form and doesn't re-enable a disabled account.
Pressing Enter in a text field saves your edits with **Update**. The form also shows the user's **Last Login**, the first thing to check when an offboarding ticket lands.
### Disabling a user
Disabling is what most offboarding tickets actually need. Click the disable icon on the user's row (or in their form) and confirm *Disable user "{name}"?* SimpleRisk marks the account disabled, signs the user out right away, and they can't sign in again until you enable them. Their record stays, and their attribution on every risk they submitted, owned, or commented on stays. The audit trail is intact. Enabling needs no confirmation: click the same icon on a disabled user's row.
We recommend disabling rather than deleting in nearly every offboarding case. The team has been telling customers this for years on the support side: deletion severs the user from every risk, mitigation, comment, and audit-trail entry that referenced them, with no undo. Disabled accounts give you the same effective result, since they can't log in, without the data loss. Reach for delete only when the account was created in error.
### Deleting a user
If deletion is the right answer, click the trash icon on the user's row and confirm *Delete user "{name}"?* The dialog spells out the consequence: the account is permanently removed, along with its team memberships, permissions, and multi-factor authentication setup. Any active sessions end.
What survives: existing audit-trail entries, which keep pointing at the now-orphan user. What doesn't: the user's appearance in dropdowns going forward, and any team or stakeholder associations. Risks the user owned still exist, but the **Owner** field can no longer resolve to a name.
The only built-in safeguards are that an admin can't delete or disable themselves: the page refuses with "An admin can't delete itself." (or "...disable itself."). There's no guard against deleting the last *other* admin, so leaving exactly one admin in your org is risky: if that one account gets locked out, you're recovering from the database.
For a planned offboarding where you want both the audit trail intact *and* the leaver's risks reassigned, the pattern most customers use is: disable the user, bulk-reassign their risks via export-edit-import using the Import/Export Extra, then leave the disabled record in place.
## Teams
A team is just a name. Users join teams, and risks, mitigations, and tests can each be tagged with one or more teams of their own. The page is the Settings Hub's **Teams** tile (Settings cog → **Teams**).
In Core SimpleRisk, team tags act as filters on reports and dashboards, useful for "show me the risks Finance owns", but they don't by themselves restrict who can see what. The [Team-Based Separation Extra](https://support.simplerisk.com/kb/03-06-team-based-segregation?hsLang=en) turns the same membership into actual data segregation. Without it, every user with the relevant view permission sees every risk regardless of team.
The page follows the same shape as Users and Roles: a searchable list of teams on the left, each with a member count, and the selected team on the right. Select a team by clicking its name. The address updates, so you can share a link to a specific team.
### Creating, renaming, and deleting a team
Click **New team**, type a **Team name** (50 characters max), and save. Creating a team assigns it to every existing administrator, since admins see every team by definition. If the [Organizational Hierarchy Extra](https://support.simplerisk.com/kb/03-04-organizational-hierarchy?hsLang=en) is installed, the team is also assigned to the default business unit.
To rename, select the team and use **Rename team**. To remove one, use **Delete team** and confirm *Delete team "{name}"?* The dialog notes that everyone is removed from the team and it's removed from anything it was assigned to, and that this can't be undone. You can't delete a team currently tagged on a risk while Team-Based Separation is active; SimpleRisk blocks with "Cannot delete this team, because there are risks that are currently using it." to prevent a team's risks from silently vanishing from the views of the people who could see them. Reassign first, then delete.
### Choosing who is on a team
The selected team opens on its **Members** list, with a heading like *3 of 41 users are in this team*. Use **Search members** to filter it. Click a member's name for a short details popup if two people share a similar name.
- **Add team member(s)** opens a picker listing everyone who isn't in the team yet. Search, tick as many people as you like (the count of selected users updates as you go, even while you search), and confirm. Your selection survives changing the search text.
- **Remove from team** takes a person out.
Membership saves as you go, with a toast confirming each change. There's no Update button to forget.
Two behaviors worth knowing. The list doesn't include administrators. They're members of every team by definition, so listing them would be noise, and the member count beside each team excludes them for the same reason. If a count looks lower than you expect, that's why.
The same membership is editable from the user side: the **Team(s)** multi-select on a user's **Teams and sign-in** card edits the same data. Use whichever side is convenient.
### How team membership affects visibility
This is the part admins frequently misunderstand. Team membership in *Core* SimpleRisk does not gate what a user can see. A user with the **Risk Management** permission sees every risk on the system, regardless of team. Team tags are a filter dimension on reports and dashboards, not an access control.
What turns membership into segregation is the Team-Based Separation Extra. With it activated, risk lists and dashboards filter each record's team assignment against the viewer's own team membership: users see only risks tagged to teams they belong to, plus untagged risks (treated as universally visible). Admins still see everything.
This explains a recurring confusion in support: "I added the user to the Finance team and they still see Engineering's risks." The answer in nearly every case is that Team-Based Separation isn't installed, and the team tag on its own does no gating.
## Roles
A role has a name, an **administrator** flag (does this role grant superuser?), and a **default** flag (do new SAML/LDAP users land here under just-in-time provisioning?). Its responsibilities are the permissions users with that role start with. The page is the Settings Hub's **Role Management** tile (Settings cog → **Role Management**).
Like Users and Teams, it's a searchable list of roles on the left and the selected role on the right. Search with **Search roles**, and use the **All roles** / **Administrators** chips to flip between every role and only the administrator ones. The selected role's name also appears in the breadcrumb.
### The roles that ship with SimpleRisk
A fresh install has exactly **one** seeded role: **Administrator**. Every other role on a running system was created by an admin or by an Extra at activation time. The Administrator role can't be edited or deleted ("The Administrator role cannot be modified."), and its trash icon is dimmed with a tooltip saying so.
This shapes the rollout. The first thing most admins do is build a small set of role bundles that match how they actually run access: a Risk Manager role for risk-management work, a Compliance role for assessment and framework permissions, a Read-Only role for view-only auditors. There's no shipped catalogue. Every customer's permission discipline differs, and a shipped catalogue would be wrong for every customer in slightly different ways.
### Creating a role
Click **New role** above the list, name it, and save. Names must be unique; if two admins add the same name at the same moment, the second gets "The role name already exists." rather than a duplicate. The new role starts with no permissions, no administrator flag, and no default flag, and opens straight away so you can start ticking responsibilities.
### Setting a role's responsibilities
Select the role and use the **Role responsibilities** card. It's a tree of permission checkboxes grouped by area. **Changes save automatically**: tick or clear a box and a toast confirms it a moment later. Rapid clicks are batched, so ticking ten boxes quickly doesn't fire ten saves. If a save fails, the page reloads what's actually stored rather than leaving boxes that look saved but aren't.
Two controls sit beside the tree's header:
- **Grant Admin / Remove Admin** — toggles the role's administrator flag, also with no Update step. While it's set, every permission is checked and locked, and the card says *Responsibilities cannot be edited while the role is an administrator role.*
- **Make this the default role** — the star beside a role's name in the list marks the default. Only one role can hold it at a time, and clicking another role's star moves it. The default role is where new SAML/LDAP users land under JIT provisioning.
The full catalogue of permissions, what each grants and which UI section it gates, lives in [Permission Reference](https://support.simplerisk.com/kb/03-03-permission-reference?hsLang=en). When in doubt, lean toward not granting. AC-6 *Least Privilege* is what auditors look for; "we gave everyone Risk Manager because it was easier" is not a defence.
Saving propagates to every user assigned to that role. SimpleRisk recomputes each affected user's effective permissions and refreshes their active sessions in place, so a user whose role gained or lost a permission sees the change on their next page load without having to log out and back in.
### Assigning roles to users
A role only affects access once it's assigned, and that happens on the user's form, in the **Role and responsibilities** card described above. Both the **Role** field and the permission checkboxes are there, so you can give one person a single extra permission without inventing a new role for the difference.
### Deleting a role
Click the trash icon on the role. If nobody holds it, the dialog just says so and asks you to confirm. If users do hold it, the dialog says how many and asks you to choose a role to **Move these users to**, and the delete is blocked until you pick one. Those users lose the responsibilities the old role gave them and gain the new role's, and active sessions refresh in place. If the deleted role was an administrator role, the moved users' administrator status follows the replacement role.
Choosing the replacement explicitly is deliberate. An earlier version moved everyone to the default role silently, which was fine when you remembered what the default was and a surprise when you didn't.
## How the three layers compose
The cleanest way to understand the model is a worked example. Suppose Alice belongs to the Finance team and has the **Administrator** switch on.
She can do everything. Administrator is the superuser switch: every permission check passes, every team is implicitly hers, every page renders. The Finance membership is decorative, since she'd see every team's risks regardless. This is why the user form locks the team list and the responsibilities when you turn Administrator on: there's no practical difference between "a team" and "all teams" for an admin user.
Now turn Administrator off and give Alice a custom **Risk Manager** role you've created — one that grants the **Risk Management**, **Submit Risks**, **Modify Risks**, **Plan Mitigations**, and **Close Risks** permissions, with no admin flag. Each layer pulls its weight:
- **User**: Alice authenticates as `alice`. The account exists, she's enabled, MFA's on. That gets her past the login.
- **Role**: Risk Manager. The five permissions her role grants are loaded into her session at sign-in. Pages enforcing a permission she doesn't hold (the Settings Hub, framework administration, the user-management pages) redirect or 403. Pages enforcing one she does (the risk register, mitigation planning) render normally.
- **Team**: Finance. With Team-Based Separation off (Core), that membership only filters her dashboard saved-views; she still sees every risk her permissions allow. With the Separation Extra on, the same row gates her view: Alice sees only risks tagged to Finance, plus untagged risks. Other teams' risks are filtered out of every list, every report, every dashboard.
Each layer does one job. The user record is "who you are." The role is "what kinds of operations you can perform." The team is "which records those operations apply to" — but only when the Separation Extra promotes membership from a label into a control. Conflating the layers fights the model and produces brittle results.
## Common pitfalls
- **Granting Risk Manager (or worse, Admin) to everyone "to keep it simple."** This shows up in small teams that grew. Six months later the audit conversation asks who can approve a risk and the answer is "everyone" — not what auditors are looking for. Build the smallest role that does the job. AC-6 *Least Privilege* is testable; "we gave them all admin" is not.
- **Role sprawl.** The opposite trap. Every department asks for a custom role; the product manager wants a Product role, the legal reviewer wants a Legal role, and a year later there are 40 roles nobody can keep straight. Build roles around *what someone does*, not *what team they belong to*. Risk Reviewer, Risk Submitter, Compliance Analyst — those scale. Marketing-Manager-Role-V2 doesn't.
- **Deleting users instead of disabling them.** Deletion is permanent and severs attribution on every record. Disabling stops the login while preserving the audit trail. Disable as the default; reach for delete only when the account was created in error.
- **Treating teams as roles.** "Put the security analysts in a Security team and grant the team some permissions." Teams don't carry permissions. Every attempt ends in confusion when the next admin tries to read the access model. If the analysts need different permissions, build a role.
- **Treating roles as teams.** "Create a Finance role that scopes data to Finance's risks." Roles don't scope data. Every attempt ends in either over-broad access or wildly over-engineered roles the codebase doesn't support. If you need data segregation by team, the Team-Based Separation Extra is the right answer.
- **The single-admin org.** One admin, no backup, no documented recovery plan. The admin leaves on a Friday, IT disables their IdP account on Monday, and nobody on the remaining team can get into the Settings Hub. Always have at least two admin accounts on a production instance, with at least one a service-style account whose credentials live in the org's privileged-access tooling rather than in one human's head.
## Related
- [The Permission Model](https://support.simplerisk.com/kb/03-02-the-permission-model?hsLang=en)
- [Permission Reference](https://support.simplerisk.com/kb/03-03-permission-reference?hsLang=en)
- [Team-Based Segregation](https://support.simplerisk.com/kb/03-06-team-based-segregation?hsLang=en)
- [Organizational Hierarchy](https://support.simplerisk.com/kb/03-04-organizational-hierarchy?hsLang=en)
- [Local Authentication and Password Policies](https://support.simplerisk.com/kb/04-01-local-authentication-and-password-policies?hsLang=en)
- [Multi-Factor Authentication](https://support.simplerisk.com/kb/04-02-multi-factor-authentication?hsLang=en)
- [FAQs](https://support.simplerisk.com/kb/faqs?hsLang=en)
- [SimpleRisk Extras](https://support.simplerisk.com/kb/simplerisk-extras?hsLang=en#main-content)
- [Vulnerability Management Extra](https://support.simplerisk.com/kb/simplerisk-extras?hsLang=en#vulnerability-management-extra)
- [Team Separation Extra](https://support.simplerisk.com/kb/simplerisk-extras?hsLang=en#team-separation-extra)
- [Import-Export Extra](https://support.simplerisk.com/kb/simplerisk-extras?hsLang=en#import-export-extra)
- [Administrator Guide](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#main-content)
- [00 About This Guide](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#00-about-this-guide)
- [01 Installation and Deployment](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#01-installation-and-deployment)
- [02 Upgrades and Maintenance](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#02-upgrades-and-maintenance)
- [03 Users and Permissions](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#03-users-and-permissions)
- [04 Authentication](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#04-authentication)
- [05 Customization](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#05-customization)
- [06 Configuring Risk and Compliance](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#06-configuring-risk-and-compliance)
- [07 Integrations](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#07-integrations)
- [08 The API](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#08-the-api)
- [09 Encryption and Data Security](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#09-encryption-and-data-security)
- [10 Workflows and Automation](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#10-workflows-and-automation)
- [11 Reporting and Auditing](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#11-reporting-and-auditing)
- [12 Operations](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#12-operations)
- [13 Reference](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#13-reference)
- [User Guide](https://support.simplerisk.com/kb/user-guide?hsLang=en#main-content)
- [00 Foundations of GRC](https://support.simplerisk.com/kb/user-guide?hsLang=en#00-foundations-of-grc)
- [01 Risk Management](https://support.simplerisk.com/kb/user-guide?hsLang=en#01-risk-management)
- [02 Compliance Management](https://support.simplerisk.com/kb/user-guide?hsLang=en#02-compliance-management)
- [03 Governance](https://support.simplerisk.com/kb/user-guide?hsLang=en#03-governance)
- [04 Asset and Data Inventory](https://support.simplerisk.com/kb/user-guide?hsLang=en#04-asset-and-data-inventory)
- [05 Threat and Vulnerability Management](https://support.simplerisk.com/kb/user-guide?hsLang=en#05-threat-and-vulnerability-management)
- [06 Assessments](https://support.simplerisk.com/kb/user-guide?hsLang=en#06-assessments)
- [07 Incident Management](https://support.simplerisk.com/kb/user-guide?hsLang=en#07-incident-management)
- [08 Audit and Reporting](https://support.simplerisk.com/kb/user-guide?hsLang=en#08-audit-and-reporting)
- [09 Day-to-Day SimpleRisk](https://support.simplerisk.com/kb/user-guide?hsLang=en#09-day-to-day-simplerisk)
- [10 Continuous Improvement](https://support.simplerisk.com/kb/user-guide?hsLang=en#10-continuous-improvement)
- [SimpleRisk User Guides](https://support.simplerisk.com/kb/simplerisk-user-guides?hsLang=en)
- [Troubleshooting](https://support.simplerisk.com/kb/troubleshooting?hsLang=en)
- [SimpleRisk Hosted](https://support.simplerisk.com/kb/simplerisk-hosted?hsLang=en)
- [How To videos](https://support.simplerisk.com/kb/how-to-videos?hsLang=en)
[](https://www.simplerisk.com)
Copyright © 2026, SimpleRisk, Inc.