DocsEveryday work

Approvals & delegation of authority

Updated 2026-10-07

Almost nothing important in Zovos takes effect because someone clicked save. Policies, finding closures, risk acceptances, vendor onboardings, monitoring workpapers, audit reports, board minutes and model approvals all become authoritative only when a second person signs them. This article explains how that routing works and what you will see when a decision reaches you.

Every governed decision lands in one queue, opened from the topbar pill or from the Dashboard's approvals panel. The drawer is titled Approvals queue. The items awaiting your sign-off come first, counted in the header. Below them, under In the queue, sit the other pending items you are allowed to see but cannot sign. Each of those says why, for example that you submitted it or that the delegation-of-authority matrix routes it to another role. The topbar pill counts only the first group. It loads a page at a time and says so as soon as a page comes back full, with a control to widen the window, so a long queue is never quietly truncated.

Each item carries:

  • A change preview shows the specific diff you are signing, not a summary of it.
  • An effect sentence in plain language makes the button say what will happen. A policy reads Approve & publish. A finding closure reads Approve closure. A vendor reads Approve & onboard. A monitoring review reads Sign off workpaper.
  • A return path that is not a rejection lets you send the item back. It is usually Request changes, which sends the item back to its author with your reasons.
  • A rationale field, which is required. Every affirmative and every return is recorded with the words you typed.
  • Where the record has a screen of its own, an Open link takes you to it. For a board meeting, it opens that meeting's detail.

If you submitted the item yourself, the drawer says so and gives you no decision buttons. You submitted it, so it is not yours to approve.

Routing comes from the delegation-of-authority matrix, which lives in Governance settings and is editable by your workspace owner. Each cell in the matrix pairs an object type with a severity and names two things. The first is which roles may sign, and the second is how many distinct signers are required.

The defaults follow the way a bank or credit union already delegates authority:

  • Critical items require two distinct signers. This four-eyes rule draws the signers from your owner and risk-approver roles.
  • High, medium and low items require one signer. A high item goes to the owner role by default, and a medium or low item to the owner or risk-approver role.
  • Policies route by document tier. A policy goes to the board. A standard, procedure or guideline goes to a single management signer from the owner role.
  • The internal audit plan always goes to the audit committee. That holds regardless of how the rest of the matrix is set.

Changing the matrix is itself an audited change, and each cell must name at least one role and a signer count before it can be saved.

Small teams hit a real problem. Sometimes nobody else in the institution holds the permission a decision requires. Zovos does not block the work or pretend a second person existed. It offers an audited sole-operator override instead. The drawer asks for a justification in addition to the rationale, the decision proceeds, and the audit row is tagged as a sole-operator action so an examiner sees exactly what happened and why.

Above the matrix sits the Authority Engine, which checks at decision time whether the person deciding was actually delegated that authority. That check includes delegations with an expiry. It runs in one of three modes, which are Off, Monitor, and Enforce. Monitor is the default. Every decision is checked and recorded but never blocked, so you can read the authority exceptions report for a few cycles before turning enforcement on.

In Enforce mode a decision outside someone's delegation is stamped and not applied, unless the signer supplies a justification. Beside the clean result of within authority, the authority exceptions report records five outcomes:

  • Escalated. The decision exceeded the signer's authority, and the row names the nearest role that does cover it.
  • Lapsed authority. A delegation existed, but it had expired.
  • Blocked · no grant. No covering delegation existed at all.
  • Break-glass override. The signer supplied a justification and the decision proceeded. It is filed as an authority exception for ratification afterwards. It answers the same community-bank reality as the sole-operator override, and it is recorded just as visibly.
  • Monitor-flagged. This is what Monitor mode records. The decision proceeded, and the row says what enforcement would have done instead.

An affirmative decision does three things at once. It applies the change. It writes the decision, signer and rationale to the audit trail. It also appends a hash-chained row to the proof ledger. That ledger row is what lets you prove, months later, that the approval existed in that form on that date.

Approvals are deliberately not automatable. Zovos publishes a Zapier app and supports Make and n8n, but no governance decision is exposed to them. You can automate opening a finding, but you cannot automate signing one.

Approvals are never assignable to a named individual. Sometimes a decision is stuck because the role it is waiting on cannot act. In that case you can Reassign it from the drawer. That retags the waiting signer slot with a different required role, and it requires a rationale that goes on the record. The picker offers only live roles that hold the permission the decision needs, and never the reserved examiner role, so a reassignment cannot park an item on a role with no authority to sign it. Reassigning is an administrative act gated on settings permissions instead of on the permission to approve. That keeps unsticking a queue and deciding an item in separate hands.

A reassignment you keep having to make is still a signal to fix the delegation-of-authority matrix in Governance settings, which is the record an examiner will read anyway. Roles and what each one can approve are covered in Roles & permissions.