A delegation of authority matrix, often just called an authority matrix, is the table that answers, for every significant decision in an organization, who may take it, up to what limit, and under which conditions. Building one that works takes seven steps: establish the formal authority baseline, inventory the decisions rather than just the amounts, design the levels, set approval limits from transaction data, handle sub-delegation and absence, reconcile the matrix with your systems, and build the machinery for exceptions and change.
This guide walks through each step the way we run them in real engagements across the UAE and Saudi Arabia, including the two places where most matrices fail: thresholds inherited from a previous era, and an ERP that quietly enforces a different matrix than the one the board approved.
What a DoA matrix is, and the one-minute test
The matrix is the central artifact of a delegation of authority framework. Decisions run down the side, roles run across the top, and each cell says what that role may do for that decision: approve to a limit, recommend, be consulted, or be informed. Around the matrix sits the rest of the framework: the governing policy, sub-delegation rules, system enforcement and the exception route.
Step 1: Establish the authority baseline
All delegated authority flows from somewhere: a law, articles of association, a board charter, a shareholder resolution. Before designing anything, collect these instruments and write down what they actually say about where authority originates and what may be delegated at all. Part of that answer is the list of matters the board may not delegate: strategy and the annual budget, dividends, material acquisitions and disposals, related-party transactions, appointing the chief executive and the external auditor. These reserved matters belong at the top of the matrix, stated explicitly, so nobody wastes a cycle wondering whether they can be pushed down.
The baseline also has an external face. In the UAE and Saudi Arabia, banks, notaries and counterparties do not act on an internal DoA; they act on the commercial register and on notarized powers of attorney. The internal matrix and those external instruments must tell the same story, and part of this step is listing every live PoA and checking it against what the matrix will say. In GCC group structures and government entities this exercise regularly produces surprises, because the formal position and the operating assumption drifted apart years ago. Every later argument about the matrix is settled by this baseline, so it is worth doing properly.
Step 2: Inventory decisions, not just amounts
The classic mistake is to treat the DoA as a table of financial limits. Money is one column. A complete inventory covers the decisions the organization actually takes: procurement commitments and variations, contract signature, budget transfers, hiring and termination by grade, salary actions, write-offs, policy exceptions, opening bank accounts, initiating litigation, accepting donations, releasing data. For each, record who decides today, who must be consulted, and who merely finds out afterwards. The inventory usually runs to between eighty and two hundred decision types, and the act of listing them is itself clarifying: decisions nobody owns become visible for the first time.
Step 3: Design the levels and set thresholds from data
Authority levels should match the structure you have, not the one on a five-year-old organization chart. Board, board committees, chief executive, C-level, director, manager: however many tiers are real, the matrix should use exactly those. Then set the approval limits from evidence. Pull a year of transactions and approvals and look at the distribution: where is senior time being spent ratifying decisions that carry no meaningful exposure, and where do large commitments pass with thin scrutiny. Thresholds inherited from an older, smaller organization are almost always wrong in both directions at once, wasting executive attention at the bottom and leaking risk at the top. Two conventions keep the limits honest: they assume the spend is within approved budget, with unbudgeted items escalating one level, and they apply cumulatively where splitting is possible, which the next step returns to.
| Decision | Section Head | Director | C-level | CEO | Board |
|---|---|---|---|---|---|
| Operating expenditure commitment | to 50 | to 250 | to 1,000 | to 5,000 | above 5,000 |
| Payment release (per bank mandate) | no authority | joint, two signatories | joint, two signatories | joint above 1,000 | mandate changes only |
| Contract variation on approved project | recommend | to 10% of value | to 20% of value | to 35%, above returns to original approver | informed |
| Hiring within approved budget | recommend | to specialist grades | to director grade | director and below; C-level with board approval | appoints CEO and C-level |
| Write-off of receivable | no authority | to 25 | to 250 | to 1,000 | above 1,000 |
| Exception to approved policy | no authority | recommend | consulted | approve and report | informed quarterly |
Step 4: Decide the rules around the matrix
Four sets of rules turn a table into a framework. Sub-delegation: may a holder pass authority down, to whom, within what limits, and recorded where. Absence and acting arrangements: who decides when the approver is on leave, and what an acting appointee may and may not do, decided now rather than during the emergency. Joint authority: which decisions require two signatures rather than one, starting with payment release, where GCC bank mandates almost universally demand dual signatories, and extending to any decision where the initiator must never be the approver. And cumulative limits: whether a threshold applies per transaction or per counterparty per year, because splitting one commitment into four approvable pieces is the oldest trick in procurement.
Step 5: Reconcile the matrix with your systems
Authority lives twice: once in the approved document and once in the workflow configuration of your ERP, procurement system and HR system, set up by an implementation team years ago and rarely revisited. In our delegation of authority engagements across the region, a mismatch between the two is the single most common finding, and the one auditors reach first, because the auditor tests the system against the paper. Reconciliation means extracting the approval chains actually configured, comparing them cell by cell against the matrix, fixing the divergences deliberately in one direction or the other, and assigning a named owner for keeping the two aligned whenever either changes.
Step 6: Build the exception machinery
Every matrix meets reality within a month: an urgent decision with the approver unreachable, a genuine case the matrix never anticipated. A framework without a legitimate route for these gets bypassed, and each bypass teaches the organization that the matrix is advisory. So build the route: who may authorize in exceptional circumstances, how the exception is recorded, and how it is ratified afterwards. A good exception log is not a record of failure; it is the requirements list for the next revision of the matrix.
Step 7: Keep it alive
The matrix should be reviewed on a fixed cycle, annually at minimum, and event-driven on restructuring, and every change should flow to the systems that enforce it. Organizations that manage the DoA this way stop rebuilding it from scratch every three years. The furthest step is to hold the DoA as part of a connected digital source of truth, where each authority is linked to the processes it governs and the policies it enforces. That connection is the difference between a document and an operating model.
This is not theoretical. We have built connected models of this kind for organizations including a retail group operating across seventeen countries, an energy and automotive services group in Saudi Arabia, and one of the Gulf's leading health insurers, in each case linking operational delegations of authority to the processes and policies they govern in one governed model.