---
title: 03.06 Team-Based Segregation
description: Core SimpleRisk's team-based segregation — the always-on team filter that scopes which records a user can see based on team membership and per-record…
---
[Skip to content](https://support.simplerisk.com/kb/03-06-team-based-segregation#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.06 Team-Based Segregation
## Core SimpleRisk's team-based segregation — the always-on team filter that scopes which records a user can see based on team membership and per-record team assignment, with admin bypass and unassigned-record fall-through behavior.
## Why this matters
Teams are SimpleRisk's basic unit of record-level access. A user assigned to the "Engineering" team sees risks, mitigations, and tests assigned to "Engineering"; they don't see records assigned only to "Finance." The team filter runs on every list query the application produces; it's how a 50-team install keeps each team's view of the register down to a tractable subset.
The honest scope to know up front: **the Core team filter is always on, has no master toggle, and is not the same thing as the Separation Extra**. Core's team filter answers *which records can a user see* based on team membership. The Separation Extra (see [Separation of Duties](https://support.simplerisk.com/kb/03-05-separation-of-duties?hsLang=en)) adds a finer role-based filter on top — within the records the team filter would let the user see, the Extra further controls visibility based on the user's role relative to that record. If you've never activated the Separation Extra, the team filter described here is your entire access-control surface for record-level visibility.
The other thing worth knowing: **Core team segregation has a permissive default for unassigned records**. A risk with no team assignment is visible to every user, regardless of their team membership. This is intentional (the system shouldn't trap orphaned records where nobody can see them) but it surprises operators who assume the team filter is strict. If a user reports "I see risks I shouldn't be able to see," check the team assignment first — an unassigned risk falls through to everyone.
The third thing: **admins bypass the team filter entirely**. A user with `user.admin = 1` sees every record, every team, every assignment. The admin's view doesn't reflect what a non-admin user sees, so a "let me check what you can see" support session from an admin account is misleading; use a non-admin test account to validate team-segregation configurations.
## Before you start
Have these in hand:
- **Admin access** to manage teams (Settings cog → Settings Hub → **Teams** tile) and to assign users to teams (Settings cog → Settings Hub → **User Management** tile).
- **A planned team structure** that maps to your operational reality. Common patterns: per-business-unit teams ("Finance," "Engineering"), per-function teams ("Application Security," "Vendor Risk Management"), per-region teams ("EMEA," "APAC"). Mix as fits your program; teams aren't hierarchical, so flat-list is the natural shape.
- **An understanding of the unassigned-record default**. The Core filter falls through for records with no team assignment. If you need strict team-only visibility (no fall-through), the Separation Extra's `allow_all_to_risk_noassign_team = '0'` setting is the lever — but that's an Extra-gated feature.
## Step-by-step
### 1. Define your teams
Settings cog → Settings Hub → **Teams** tile opens the team management page (`simplerisk/admin/team_management.php`). The page lists existing teams and lets you add, rename, or delete teams.
To add a team:
1. Enter the team name in the **Add a New Team** input.
2. Click **Add**.
3. The team appears in the catalog, ready to be assigned.
Naming guidance: use names that match the operational language of the organization. "Engineering" beats "ENG-01"; the names show up in dropdowns, dashboard filters, and reports throughout the application. If teams nest conceptually (Finance has Treasury and Accounting), capture the hierarchy in the name ("Finance.Treasury") since the team model itself is flat. For real organizational hierarchy, the [Organizational Hierarchy](https://support.simplerisk.com/kb/03-04-organizational-hierarchy?hsLang=en) Extra is the right tool.
Renaming or deleting a team affects every record currently assigned to it; renaming is safe, because assignments follow the team itself rather than its name, but deleting strands them. Reassign records to a different team before deleting, or accept that the deletion implicitly removes the team-based-visibility constraint from those records.
### 2. Assign users to teams
Settings cog → Settings Hub → **User Management** → \[user\] opens the user record. The **Teams** field is a multi-select; pick all teams the user belongs to. Saving the user record updates their membership.
Patterns:
- **Most users belong to one team** — their primary working team.
- **Cross-functional users** (auditors, leaders) belong to multiple teams; the union of their teams' records is what they see.
- **New admins automatically get all teams.** Promoting a user to administrator assigns them to every existing team. This is a defensive measure: if the admin flag is later revoked, the user retains their assigned team memberships and isn't suddenly cut off from everything.
### 3. Assign teams to records
The team-assignment surface lives on the record itself. The patterns:
- **Risks** — the risk submission form (sidebar: **Risk Management → Submit Your Risks**) and the risk details edit view (sidebar: **Risk Management → Plan Your Mitigations**) both have a **Team** multi-select. Assignment is multi-team; a risk can be visible to "Engineering" *and* "Application Security" simultaneously.
- **Mitigations** — the mitigation form on each risk has a **Team** multi-select. The mitigation carries its own team assignment, independent of the risk's. to teams independently of the parent risk's teams.
- **Compliance tests** — the test definition has a **Team** multi-select. The test carries its own team assignment.
- **Compliance audits** — the audit record has a **Team** multi-select. The audit carries its own team assignment.
A few entities are *not* team-segregated in Core (notably assets — there is no `asset_to_team` table). Asset-related visibility comes from the Asset Management Extra and from the team-segregation Extras layered on top, not from a Core asset/team join. If you need strict per-team asset visibility, that's an Extra-driven configuration; Core asset visibility is broader.
### 4. Verify the filter with a non-admin account
Admins bypass the team filter; the admin's view is *not* representative. To validate the configuration:
1. Pick or create a non-admin test user with a single team membership (say, "Engineering").
2. Log in as that user.
3. Open **Risk Management → Plan Your Mitigations** and confirm the visible risks are the union of: - Risks assigned to "Engineering" (the user's team), AND - Risks with no team assignment (the fall-through default).
4. Confirm the user does *not* see risks assigned only to teams the user isn't a member of.
If the visible set is wider or narrower than expected, the cause is usually one of: an unexpected team assignment on the user record (check Settings cog → Settings Hub → **User Management** → \[user\] → **Teams**), an unassigned record falling through (assign it to a specific team), or the Separation Extra is active and adding a layer of role-based visibility on top.
### 5. (Optional) Tighten the unassigned-record fall-through
By default, records with no team assignment are visible to every user — the Core filter's fall-through. For programs that need strict team-only visibility, the path is:
- **Operational discipline**: enforce that every new risk, mitigation, test, and audit gets at least one team assignment at submission time. This is the lowest-friction approach but depends on user behavior.
- **The Separation Extra** (see [Separation of Duties](https://support.simplerisk.com/kb/03-05-separation-of-duties?hsLang=en)) adds the `allow_all_to_risk_noassign_team` setting; setting it to `'0'` makes unassigned risks invisible to non-team users. Per-feature equivalents exist for documents (`allow_all_to_document_noassign_team`) and assets (`allow_all_to_asset_noassign_team`).
There's no Core-only setting for the fall-through; the operational-discipline approach or the Extra are the two options.
### 6. Plan for team changes
A common operational mistake: a team is renamed or restructured, but record-level team assignments aren't updated. Records keep pointing at the old team (which still works, since assignments are by `value`, not by display name) — but if the team is *deleted*, the assignment becomes orphaned and the records fall through to everyone-visible.
Reasonable cadence:
- **Quarterly**: review the team catalog. Are all teams still in active use? Are there teams that should be merged or split?
- **At org-restructure events**: walk the team-to-record assignments and re-assign as needed before deleting the old teams.
- **At user-onboarding**: confirm the new user's team assignments match their actual responsibilities. Default to fewer teams; broader access can be granted later.
## Common pitfalls
A handful of patterns recur with team-based segregation.
- **Validating from an admin account.** Admin bypasses every team filter. The admin's view is wrong by construction; use a non-admin test account.
- **Forgetting the unassigned-record fall-through.** "Why can the user see this risk? They're not on its team!" Check the risk's team assignment — if the assignment is empty, the risk is visible to everyone in Core, regardless of team membership. Either assign the risk to a team or activate the Separation Extra and configure `allow_all_to_risk_noassign_team`.
- **Deleting teams without reassigning records.** Records assigned only to a deleted team become orphaned — their assignment points at a team that no longer exists. The Core filter treats these as unassigned and falls through to everyone-visible. Reassign records to a different team before deleting.
- **Confusing teams with permissions.** A user with `submit_risks` permission can submit risks regardless of team membership; a user with no team membership but an explicit team assignment on a risk still sees that risk. Teams filter *visibility*, not actions. The two layers reason independently.
- **Trying to express hierarchy in flat teams.** Core teams don't nest. "Finance.Treasury" and "Finance.Accounting" express hierarchy in the *names* but the system treats them as two unrelated teams. For real organizational hierarchy, the [Organizational Hierarchy](https://support.simplerisk.com/kb/03-04-organizational-hierarchy?hsLang=en) Extra adds business units above the team layer.
- **Assuming the team filter is strict by default.** Core's filter is permissive: team-membership union plus unassigned-record fall-through plus admin bypass. If "strict team-only visibility" is your requirement, the Separation Extra adds the levers; Core alone won't get you there.
- **Not updating team assignments after user role changes.** When a user moves to a different team, their team membership doesn't auto-update. The user keeps seeing the old team's records and may not see the new team's records. Include team-membership review in user-management workflows for role changes.
- **Granting admin to "fix" team-visibility issues.** If a user can't see a record they should, the right answer is usually a team assignment (assign the user to the relevant team, or assign the record to the user's team). Granting admin bypasses *all* the access-control machinery, not just the team filter, and is rarely the right answer.
## Related
- [Managing Users, Teams, and Roles](https://support.simplerisk.com/kb/03-01-managing-users-teams-and-roles?hsLang=en)
- [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)
- [Organizational Hierarchy](https://support.simplerisk.com/kb/03-04-organizational-hierarchy?hsLang=en) (the Extra that adds business units above teams)
- [Separation of Duties](https://support.simplerisk.com/kb/03-05-separation-of-duties?hsLang=en) (the Extra that adds role-based visibility within teams)
- [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.