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

03.05 Separation of Duties

The Separation Extra (also called Team-Based Separation Extra) adds fine-grained role-based visibility on top of team membership — controlling whether risk owners, owner's managers, submitters, additional stakeholders, team members, and various other roles can see each other's risks, documents, tests, and audits.

Requires: Separation Extra

The role-based visibility configuration described here is added by the Separation Extra (the directory is simplerisk/extras/separation/; the Extra is also labeled "Team-Based Separation Extra" in some contexts). Without it, SimpleRisk has only the basic team-membership filter (see Team-Based Segregation) — coarser, with no per-role granularity.

Why this matters

Separation of duties is the IIA Three Lines model in action — the principle that the same person shouldn't fill conflicting roles in a workflow (the same person submitting and reviewing a risk; the same person testing and approving a control). Core SimpleRisk supports the enforcement of role separation through the level-gated review permissions and the accept/reject workflows; it doesn't support the visibility separation that mature programs need (the risk owner shouldn't necessarily see other owners' risks; the team's auditor shouldn't necessarily see audits for controls outside their scope).

The Separation Extra adds the visibility-separation layer. When activated, it gates per-role access to risk details, document details, and test/audit details based on a configurable set of toggles. The defaults are reasonable (owners see their own risks; managers see their reports' risks; submitters see what they submitted; etc.), and the configuration lets you tighten or loosen individual visibility paths.

The honest scope to know: the Separation Extra is an all-or-nothing toggle. Activating it flips the whole install into role-based-visibility mode (with default-permissive settings); deactivating it reverts to the basic team-membership-only filter. There's no partial activation — you can't enable the role-based-visibility for risks but not for documents, for example. The granularity comes from the per-feature toggles after activation, not from selective activation.

The other thing worth knowing: the Extra and team-based segregation are different layers. Team-based segregation (always on, in Core) filters which entities a user can see based on team membership. The Separation Extra adds a role-based filter on top — within the entities the team filter would let the user see, the Separation Extra further controls based on the user's role relative to that specific entity. Both filters apply when the Extra is active; the visible-records set is the intersection of the two.

Before you start

Have these in hand:

  • Admin access to activate Extras and configure the per-feature toggles.
  • A clear understanding of which separation-of-duties principles your program enforces. Generic "we want SoD" is too vague; the configuration questions are specific (should the risk submitter see other people's risks? should additional stakeholders see all of an entity's data, or just summary?). Map your principles to the specific toggles.
  • A team structure that supports the separation. The Extra adds role-based visibility within team boundaries; if your teams are too broad (every user in one team), the role-based filter doesn't add much. Consider team granularity before activating.
  • A backup before activating; the Extra modifies behavior across most of the application. Reverting is straightforward (deactivate the Extra) but a backup is the rollback path for any unexpected interactions.
  • Awareness that activation changes what existing users see. Users who previously saw all risks in their team may now see only risks they own (or a subset). Communicate the change before activation; otherwise users will report "I lost access to risks" tickets immediately after.

Step-by-step

1. Activate the Extra

Sidebar: Configure → Extras opens the Extras list. Find Separation Extra (or Team-Based Separation Extra — both labels refer to the same Extra) and click Activate. The activation:

  1. Sets the team_separation configuration setting to 'true'.
  2. Populates ~15 finer-grained settings with sane defaults (typically, owner-can-see-their-own, manager-can-see-reports', stakeholder-can-see-stakeholding, team-members-can-see-team-stuff).
  3. Writes an audit-log entry recording the activation.

The Extra doesn't add new tables; all configuration is settings-driven. Existing data is unaffected; what changes is what queries return for non-admin users.

2. Configure the per-feature visibility toggles

Sidebar: Configure → Settings (or the Separation Extra's specific configuration page in your install). The relevant settings, all stored in the settings table:

Risk visibility:

  • allow_owner_to_risk — Risk owners see their own risks. Default: '1' (true).
  • allow_ownermanager_to_risk — A risk owner's manager sees the risk. Default: '1'.
  • allow_submitter_to_risk — The user who submitted the risk sees it. Default: '1'.
  • allow_team_member_to_risk — Members of the risk's assigned team see the risk. Default: '1'.
  • allow_stakeholder_to_risk — Users on the risk's Additional Stakeholders list see the risk. Default: '1'.
  • allow_all_to_risk_noassign_team — All users see risks that have no team assignment. Default varies; for strict SoD, set to '0'.

Test / audit visibility (controls who can see test definitions and audit records for controls):

  • allow_control_owner_to_see_test_and_audit — The control's owner sees tests and audits on the control. Default: '1'.
  • allow_tester_to_see_test_and_audit — Designated testers see test and audit details. Default: '1'.
  • allow_stakeholders_to_see_test_and_audit — Stakeholders see test and audit details. Default: '1'.
  • allow_team_members_to_see_test_and_audit — Members of the assigned team see test and audit details. Default: '1'.
  • allow_everyone_to_see_test_and_audit — Everyone sees test and audit details (bypass; appropriate only for non-strict programs). Default: '0'.

Document visibility:

  • allow_document_owner_to_see_documents — Document owners see their own documents. Default: '1'.
  • allow_document_owners_manager_to_see_documents — A document owner's manager sees the document. Default: '1'.
  • allow_approver_to_see_documents — The document's approver sees it. Default: '1'.
  • allow_stakeholders_to_see_documents — Stakeholders see documents. Default: '1'.
  • allow_team_to_see_documents — Team members see documents. Default: '1'.
  • allow_all_to_document_noassign_team — All users see documents not assigned to a team. Default varies.
  • allow_all_to_see_document — All users see all documents (bypass). Default: '0'.

Asset visibility:

  • allow_all_to_asset_noassign_team — All users see assets not assigned to a team. Default varies.

To change a setting:

UPDATE settings SET value = '0' WHERE name = 'allow_stakeholder_to_risk';

Or via the admin UI's settings page if it exposes the toggles.

3. Map your separation principles to the toggle configuration

Common SoD configurations:

  • Strict SoD: only the role that performed an action sees the result. Configure: allow_owner_to_risk = '1' (owners see their own), all other "who can see risks" toggles set to '0'. Result: a risk visible only to its owner; managers and stakeholders need explicit assignment to gain visibility. This is appropriate for highly-regulated programs (financial services, classified contexts) but produces operational friction.

  • Moderate SoD: owners + managers + the assigned team see the records. Configure: allow_owner_to_risk = '1', allow_ownermanager_to_risk = '1', allow_team_member_to_risk = '1'; stakeholder/submitter toggles can go either way. Result: the immediate working group sees the records; broader visibility requires explicit assignment. This is the typical production configuration for most programs.

  • Permissive SoD with team-only filter: anyone on the team sees the team's records, regardless of role. Configure: allow_team_member_to_risk = '1' plus most other toggles also '1'. Result: team membership is the primary filter; role-based visibility doesn't add much. Appropriate for low-friction programs where team-membership-only filtering is the operational reality.

The right configuration depends on the program's compliance requirements and the friction the team will tolerate. Start with the defaults; tighten specific toggles as audits or operational needs surface.

4. Test the configuration with non-admin accounts

Admins bypass all permission and visibility checks. The admin's view of "what the configuration produces" is not representative.

To test:

  1. Create or pick a test user account with limited permissions and team membership.
  2. Log in as that user.
  3. Walk through the screens that should be affected — the risk list, the document list, the audit list — and verify the visibility matches expectations.
  4. Note any cases where the user sees something they shouldn't, or doesn't see something they should.
  5. Adjust the toggles based on findings; re-test.

Iterate until the test user sees what the SoD design intended. Then go live.

5. Document the configuration

The configured toggles are operational decisions; they should live somewhere the next operator (or your future self) can find them. Options:

  • Capture the relevant SELECT name, value FROM settings WHERE name LIKE 'allow_%'; output in your operations runbook.
  • Document the rationale for each non-default setting.
  • Schedule periodic reviews (quarterly is reasonable) to confirm the configuration still matches the program's needs.

Without documentation, the toggle configuration is implicit and the rationale is lost; future operators may toggle settings without understanding the impact.

6. Plan for deactivation (if needed)

Deactivating the Extra:

  1. Sets team_separation to 'false'.
  2. Zeros out (sets to '0') the ~15 per-feature toggles.
  3. Reverts to basic team-membership-only filtering.

Deactivation is reversible (re-activate to restore the Extra), but the per-feature configuration is reset on deactivation — re-activation gives you the defaults again, not your prior custom configuration. Document your custom configuration before deactivating so it can be restored manually.

Common pitfalls

A handful of patterns recur with the Separation Extra.

  • Activating without communicating the change. Users who previously saw all team risks suddenly see fewer. The support-ticket spike is predictable; communicate the change in advance, explain the rationale, and provide the operational path for users who legitimately need broader visibility (additional stakeholder assignment, role changes, etc.).

  • Configuring strict SoD without considering operational friction. "Only the owner sees their own risks" produces a register where every reader sees a different subset. Cross-cutting reviews, executive readouts, and audit conversations get harder. Match the SoD strictness to the program's actual compliance requirement; over-strict configuration produces friction without proportional benefit.

  • Testing only as the admin user. Admin bypasses every check. The admin's view doesn't reflect what users see. Test with a non-admin account before considering the configuration validated.

  • Forgetting that the Separation Extra and team segregation interact. The visible records are the intersection of team-membership filtering and role-based filtering. A user who's not on the team can't see the record at all, regardless of role. A user who's on the team but doesn't satisfy the role-based filter also can't see the record. Both layers apply.

  • Setting allow_everyone_to_see_test_and_audit to true while having strict SoD elsewhere. The bypass setting produces an inconsistent posture — strict separation everywhere except this one bypass. Audit findings will surface the inconsistency. Either commit to strict separation across the board or acknowledge the lighter posture explicitly.

  • Toggling settings without re-testing. Each toggle change can have downstream effects on what users see. Test after every meaningful configuration change.

  • Not coordinating with the Organizational Hierarchy Extra. Both Extras affect visibility. Activating both produces a visible-records set that's the intersection of business-unit context, team membership, and the role-based filter. Document the combined behavior; don't assume users will reason about the combination correctly.

  • Treating the Extra as a substitute for action-level permission gating. The Separation Extra controls visibility, not actions. A user who can see a risk and has the modify_risks permission can modify the risk regardless of role separation. The action-level enforcement comes from the Core permission model and from the Extras that add accept/reject workflows (e.g., the mitigation accept/reject in the standard mitigation workflow).

  • Letting the Extra's defaults stand without review. The default configuration is "permissive within the role hierarchy" — most roles can see most things. Programs that need stricter SoD have to configure explicitly; the defaults don't enforce strict separation. Don't activate and assume the defaults match your needs without reviewing.

Related

Reference

  • Permission required: check_admin for activating the Extra and configuring the per-feature toggles.
  • API endpoint(s): None specific to the Extra; the visibility filtering applies inline in the risk/asset/compliance/document CRUD endpoints.
  • Implementing files: simplerisk/extras/separation/index.php (the enable_team_separation_extra(), disable_team_separation_extra(), extra_grant_access() functions); simplerisk/extras/separation/upgrade.php (settings migrations).
  • Database tables: None specific to the Extra; all configuration in the settings table. The Extra reads from existing tables (risk_to_team, user_to_team, etc.) for the access checks.
  • config_settings keys: team_separation (boolean — Extra activation); plus ~15 per-feature toggles: allow_owner_to_risk, allow_ownermanager_to_risk, allow_submitter_to_risk, allow_team_member_to_risk, allow_stakeholder_to_risk, allow_all_to_risk_noassign_team, allow_control_owner_to_see_test_and_audit, allow_tester_to_see_test_and_audit, allow_stakeholders_to_see_test_and_audit, allow_team_members_to_see_test_and_audit, allow_everyone_to_see_test_and_audit, allow_document_owner_to_see_documents, allow_document_owners_manager_to_see_documents, allow_approver_to_see_documents, allow_stakeholders_to_see_documents, allow_team_to_see_documents, allow_all_to_document_noassign_team, allow_all_to_see_document, allow_all_to_asset_noassign_team.
  • External dependencies: None.