Appearance
Segregation of Duties
Segregation of duties is the rule that the person who does something is not the person who confirms it was done properly.
In OrviQ it is enforced structurally, at the service layer, on every governed decision.
The universal rule
The maker cannot be the checker.
Concretely, across the platform:
| The person who... | Cannot... |
|---|---|
| Proposed a mapping | Approve it |
| Requested an exception | Approve or reject it |
| Made an applicability decision | Approve it |
| Authored an assessment | Review and approve it |
| Owns a finding | Review, accept, dismiss or close it |
| Owns an action plan | Approve it |
| Approved an action plan | Verify it |
| Submitted an engagement | Decide it |
| Authored a BIA, plan or exercise | Approve or sign it off |
| Submitted an incident review | Approve the closure |
| Prepared an audit plan or engagement | Approve or sign it off |
| Coordinated a regulatory response | Approve it |
| Authored a policy | Approve its publication |
Where enforcement happens
At the service layer, not in the interface.
This matters because interface-level enforcement can be bypassed by an API call. A rule that only exists in a button's disabled state is not a control.
Beyond blocking the action, requesters are excluded from their own review queues, so a submitter never sees their own item awaiting their approval.
The Three Lines model in findings
Findings carry the clearest expression of the model.
| Line | Permission | Can do | Cannot do |
|---|---|---|---|
| Line 1 | finding.remediate | Comment, attach evidence, remediate, request reassessment | Accept, dismiss or close |
| Line 2 | finding.review | Assign, accept, dismiss, send back, close | Act on a finding they own |
| Line 2 | finding.escalate | Escalate for risk review | Escalate a finding they own |
| Independent | finding.close | Independent closure | — |
Action plans go further, requiring three distinct people: an owner (action_plan.write), an approver (action_plan.approve) and a verifier (action_plan.verify), none of whom may hold two of those roles on the same plan.
Permissions that are never auto-granted
Some permissions are excluded from every system role template, including the Tenant Administrator's all-permissions grant.
| Permission | Why |
|---|---|
tprm.assess | Governed third-party risk assessment is a professional judgement |
tprm.classify | Regulatory classification is a professional judgement |
tprm.decide | Approving a material outsourcing arrangement is a governance decision |
assessment.review_self_override | The SoD break-glass — see below |
Administering the system is not the same as exercising judgement within it
A Tenant Administrator holds tprm.manage — they can configure lifecycle dates, terminate engagements and offboard parties. They cannot assess, classify or decide.
Administrative access should not confer professional authority. Whoever maintains the platform is not thereby qualified to approve a material outsourcing arrangement.
The governed break-glass
One permission deliberately defeats a segregation rule: assessment.review_self_override lets a user approve a control assessment they authored.
It is designed to be hard to use accidentally:
| Guard | Effect |
|---|---|
| Off by default | Granted to no system role template |
| Excluded from the admin grant | Explicitly excluded from the Tenant Administrator all-permissions grant |
| Not satisfied by admin status | Administrator status alone never satisfies it |
| Requires a reason | The override requires a documented justification |
| Dedicated audit event | Raises its own distinct audit event, not a generic one |
Grant it to a custom role only if your governance model genuinely needs an emergency self-approval path — and expect to explain each use.
A related pattern applies to control_source.override_trust, which is deliberately narrower than control_source.publish and cannot be consumed by the person who granted it.
Roles and stage bindings
Workflow stages bind to tenant RBAC role keys. Segregation depends on those roles being held by different people.
A six-eye chain with one person holding both stage roles is a four-eye chain
The workflow engine enforces that the same person cannot act twice. It cannot know that your Compliance Officer and Compliance Manager roles are held by the same individual.
Review role assignments periodically against your chain configuration. This is the most common way a well-designed chain silently loses depth.
Permissions
| Action | Permission |
|---|---|
| Define workflow steps and SoD flags | workflow.configure |
| Approve transitions | workflow.approve |
| Administrative override | workflow.override |
| Self-review break-glass | assessment.review_self_override |
Example
An action plan requiring three people.
ACT-2026-0188 — Enforce MFA on remaining privileged accounts.
| Role | Person | Permission |
|---|---|---|
| Owner | IT Security Operations Manager | action_plan.write |
| Approver | Compliance Manager | action_plan.approve |
| Verifier | Senior Compliance Analyst | action_plan.verify |
What was blocked: the IT Security Operations Manager attempted to mark the plan verified after completing the work. Blocked — the owner cannot verify.
What that caught: the verifier, checking independently, found that the indicator was still failing for one account. The plan had been completed on the two accounts named in the plan; a third had been added to scope after the plan was written.
Had the owner been able to self-verify, the plan would have closed with the finding still live.
Troubleshooting
"I cannot approve my own work." That is the rule operating as designed.
"I am an administrator and still blocked." Some permissions are never auto-granted to administrators, and administrator status never satisfies a segregation check.
"A six-eye chain is only involving two people." One person holds both stage roles. Review role assignments.
"We genuinely need a self-approval path."assessment.review_self_override exists for control assessments. Grant it deliberately to a custom role, and expect each use to be audited and questioned.