Skip to content

Multi-Eye Approvals

Approval depth in OrviQ is described by how many pairs of eyes see a decision before it becomes authoritative.


The three depths

DepthStructureMeaning
Four-eyeMaker, then CheckerOne person acts; a second, independent person approves
Six-eyeMaker, Reviewer, ApproverAn independent review stage and a separate approval authority
Eight-eyeMaker, Reviewer, Approver, ManagementAn additional senior or committee stage

Each review stage enforces segregation of duties independently. A six-eye chain requires three distinct people, not two people acting twice.


Which objects use which by default

ObjectDefault chainEscalation available
Requirement demonstrationWork, Department Review, Compliance Review, Management ApprovalEscalate at compliance review
FindingWork, Review, Close
PolicyDraft, Compliance Review, Published (four-eye)Six-eye template available
ExceptionDraft, Review and Approval (four-eye)Six-eye template available
Risk acceptanceRequest, Risk and Compliance ReviewEscalate to executive or CCO approval
Applicability decisionDraft, Independent Compliance ReviewEscalate to executive or CCO approval; six-eye template available
Control mappingDraft and propose, Independent Mapping Review
Audit planDraft, Audit Review and Approval
Audit engagement sign-offFieldwork, Independent Audit ReviewEscalate to executive or CAE sign-off
Regulatory responseDraft, Independent Compliance or Legal ReviewEscalate to executive or committee approval
BIADraft, Risk and Continuity ReviewEscalate to business or committee approval
Continuity planDraft, Continuity ReviewEscalate to executive approval
Resilience exerciseConduct, Independent Review and Sign-offEscalate to executive sign-off
Resilience assessmentAssess, Resilience Review and Sign-off
Incident closureInvestigation, Independent Review and Closure Sign-offEscalate to executive or risk committee
Third-party engagementPrepare, Risk Review

Defaults are tenant-configurable. See Workflow Templates.


Transitions available at a stage

TransitionEffect
Forward or SubmitAdvance to the next stage
ApproveApprove, typically to a terminal stage
ReturnSend back to the work stage with comments
RejectDecline, to a terminal rejected stage
EscalateMove to a higher approval stage

Not every stage offers every transition. A work stage typically offers only forward.


Return versus reject

These are different acts with different consequences, and choosing correctly matters.

ReturnReject
MeansThis needs workThis should not proceed
Goes toThe work stageA terminal rejected state
The submitterRevises and resubmitsStarts again if they proceed at all
Use whenThe substance is sound and something is missing or wrongThe proposal is fundamentally not right

Most reviewer feedback is a return. Rejecting work that needed a small correction wastes the analysis behind it.


Choosing a chain depth

Choose by consequence, not by seniority of the submitter

The question is not "who submitted this?" It is "what happens if this is wrong and nobody catches it?"

  • Four-eye is right for most operational governance: mappings, ordinary exceptions, standard policies.
  • Six-eye is right where the decision has material external consequence: a regulatory response, a material outsourcing decision, a board-level policy.
  • Eight-eye is right where a committee genuinely needs to see it, and where the delay is acceptable.

Over-deepening chains is not free. A six-eye chain on routine approvals produces a bottleneck, and bottlenecks produce workarounds.


Roles at stages

Stages bind to tenant RBAC role keys — strings your administrator can remap. The workflow engine has no notion of what a role means; it routes to whoever holds the bound role.

Some stages use a resolver instead of a fixed role: owner resolves to the record's owner, owner_department_head to their department head.


Permissions

ActionPermission
Define workflow stepsworkflow.configure
Assign step responsibilityworkflow.assign
Approve workflow transitionsworkflow.approve
Administrative overrideworkflow.override

Plus the domain permission for the object being approved.


Example

A bank's chain configuration.

ObjectChainReasoning
Control mappingsFour-eyeHigh volume; the consequence of a wrong mapping is a coverage error that assurance will surface
Ordinary exceptionsFour-eyeCompliance Manager approval is proportionate
Exceptions on critical systemsSix-eyeRisk review, then CRO approval
Standard policiesFour-eyeCompliance review
Board-level policiesSix-eyeCompliance review, then executive sign-off
Risk acceptanceSix-eye with escalationRisk review, escalating to CRO where residual is beyond appetite
Regulatory responsesSix-eyeLegal review, then CRO approval — the response is a formal representation to a supervisor
Incident closure, Critical severitySix-eyeOperational risk review, then risk committee
Incident closure, otherFour-eyeOperational risk review

Volume through the chains in a quarter:

ChainDecisionsFirst-time approval rate
Four-eye1,84787%
Six-eye6261%

The lower first-time rate on the six-eye chain is the expected result, not a problem. Those are the decisions with material consequence, and 39% of them needed something changed.


Troubleshooting

"A six-eye chain approved with two people." It cannot. Each stage enforces segregation independently. Check whether the second person held both stage roles — that is a role design issue, not a workflow one.

"The final approval did not change the business state." Only the terminal stage updates business state. Check whether the chain reached its terminal stage.

"I want a different depth for one object type." Chain depth is set through workflow template bindings. See Workflow Templates.

"Escalation is not available." Not every chain has an escalation transition at every stage. Check the template.


OrviQ Enterprise Governance, Risk & Compliance Platform