Appearance
Review and Publication
Publishing a policy is a governance act. In OrviQ it runs through the same organisational workflow layer as every other governed approval.
The four-eye chain (default)
Draft and submit, then Compliance Review, then Published or Rejected.
The review stage enforces segregation of duties: the author cannot approve their own policy.
The six-eye chain
For policies warranting executive sign-off:
Draft and submit, then Compliance Review, then Executive or CCO Approval, then Published or Rejected.
Both review stages enforce segregation of duties. Which chain applies is tenant configuration — see Workflow Templates.
Choose the chain by consequence, not by seniority of author
A board-level policy and a desk procedure do not need the same approval chain. Reserve the six-eye chain for policies whose failure would matter at board level; using it everywhere makes approval a bottleneck and encourages people to route around it.
What each outcome does
The workflow engine owns the stages and the segregation rules. The policy module owns the resulting business state.
| Workflow outcome | Policy status becomes |
|---|---|
| Approved at the final stage | Published |
| Rejected | Under Revision |
| Returned | Under Revision |
This division is deliberate and is the platform-wide pattern:
The organisational workflow layer determines stages, roles and segregation. The domain module remains authoritative for its own final business state.
The workflow does not know what "published" means. The policy module does not know what four-eye means. Neither needs to.
Submitting a policy
- Ensure the policy record is complete: title, version, owner, category, effective and review dates.
- Ensure it is mapped to the requirements it addresses. Requires
policy.map. - Submit. The policy status moves to In Review.
- The review stage appears in the reviewer's Workbench with a deep link, and a notification is dispatched.
- The reviewer approves, returns or rejects.
Requires policy.write to submit.
The published-policy rule
A published policy must enter revision before re-approval
Submitting a policy already in Published is blocked.
Without this, a published policy could be re-approved without a version change — leaving two different documents that were both "the published policy", with nothing recording the difference.
To revise a published policy: move it to revision, make the changes, increment the version, and submit.
Legacy status controls
The governed approval flow bridges its outcomes onto policy status. Existing direct status controls are preserved and untouched, in line with the platform's rule of not retiring legacy behaviour while adding governed layers on top.
Use the governed flow for anything that needs an approval record.
Semantic Doctrine: Published != Compliant
Publication does NOT equal compliance
Publishing a policy is an internal milestone: it establishes that the enterprise has formalized and authorized its rules.
- Published != compliant: Having a published policy does not prove that operations satisfy external regulatory standards.
- Published != effective: Control operating effectiveness requires ongoing testing and evidence verification, regardless of publication status.
- Published != aware: Staff awareness is a separate act that requires formal attestation campaigns and individual employee acknowledgements in the Employee Portal.
What publication does and does not do
| Publication does | Publication does not |
|---|---|
| Put the policy in force across the enterprise | Certify compliance with any regulation |
| Seal an immutable record of approval and redlines | Establish that controls operate effectively |
| Enable operationalization against controls and risks | Automatically acknowledge the document to staff |
| Make it count as structural policy coverage in assessments | Satisfy regulatory obligations without evidence |
| Supersede the prior published version | Preclude the need for operational testing |
Awareness is a separate act — see Policy Attestation and Employee Portal.
Permissions
| Action | Permission |
|---|---|
| Create, update and submit policies | policy.write |
| Approve at a review stage | The role bound to that stage in the workflow template |
| Record a review | policy.review |
| Map to requirements | policy.map |
Requires the policy_governance entitlement.
Example
Policy: Third-Party Risk Management Policy v2.0.
| Stage | Actor | Outcome | Date |
|---|---|---|---|
| Draft and submit | Head of Third-Party Risk | Submitted | 4 Feb |
| Compliance Review | Compliance Manager | Returned | 11 Feb |
| Draft and submit | Head of Third-Party Risk | Resubmitted | 19 Feb |
| Compliance Review | Compliance Manager | Approved | 24 Feb |
| Executive Approval | Chief Risk Officer | Approved | 3 Mar |
| Published | — | In force | 3 Mar |
The return on 11 February carried the comment: "Section 4 sets a materiality threshold that does not match the threshold in the revised supervisory circular. Please align, and confirm whether existing arrangements need reassessment against the corrected threshold."
That return produced two outcomes: a corrected policy, and a reassessment programme for existing arrangements that would otherwise have been missed.
A chain that never returns anything is not a control. The return is the point.
Troubleshooting
"I cannot approve a policy I authored." Segregation of duties. An independent reviewer is required.
"Submission is blocked." The policy is already Published. Move it to revision first.
"The policy was approved but the status did not change." Check the workflow run reached its terminal stage. Intermediate approvals in a six-eye chain do not publish.
"I do not see the approval task." The stage is bound to a role. Check your role holds the stage's role binding in the workflow template.