How to write (or rewrite) a DOA policy that is readable, enforceable, and aligned with the way work actually happens - including governance, exceptions, and ownership.
If you need a primer on what delegation of authority covers and why it drifts, start with Delegation of Authority (DOA) 101.
Definition: A delegation of authority policy is the governing document that establishes the principles, scope, ownership, and rules by which an organization assigns, manages, and enforces decision rights and approval limits — serving as the constitutional foundation for all downstream authority artifacts including matrices, delegations, and workflow rules.
Most DOA policies fail for a predictable reason: they were written for auditors, not operators. A well-designed policy satisfies compliance requirements and functions as a working reference that managers actually use under time pressure. A January 2025 EY and Society for Corporate Governance study found that roughly 90 percent of companies maintain a DOA policy.[1] The same research found that 36 percent of organizations cite insufficient training about the policy and its usage as their single biggest challenge.[2] The problem is almost never “we don’t have a policy.” It’s that the policy was written once, lives in a shared drive, and doesn’t connect to how people actually make decisions.
This guide covers what a usable policy must contain, how to set thresholds that survive organizational scale, five principles that separate enforceable policies from shelf-ware, and the implementation checklist for getting a new or revised policy into operation.
A functional DOA policy addresses eight domains — from governance philosophy to consequence frameworks — and treats each as an operational commitment, not a section to be written and filed.
A policy that works in practice covers eight areas. These aren’t sections you draft once — they are commitments to how the organization operates that must hold up against real change over time.
The purpose and scope section establishes what the policy covers: which business units, legal entities, geographies, and decision domains are in scope. Be explicit about exclusions — what is deliberately outside the framework — or operational teams will interpret gaps as permission. The governance principles section sets the organizational philosophy: how centralized or distributed authority should be, the risk appetite that informs threshold design, and the escalation philosophy when situations fall outside the matrix.
The authority matrix reference should tell every reader exactly where the operational rules live, how to interpret them, and who maintains them. If the matrix is in a spreadsheet on a finance drive, say so — and acknowledge the limitations that creates. The delegation and sub-delegation rules section governs how authority is granted and transferred: who can delegate to whom, what limits apply to sub-delegation, and whether delegations are time-bound or permanent by default.
The exception and escalation process provides a documented path for decisions that fall outside the matrix — how to request an exception, who approves it, and what documentation is required. Without this, exceptions default to informal channels that create audit exposure. The roles and responsibilities section assigns ownership at every level: policy owner, matrix owner, process owners in business functions, system owners who configure workflow enforcement, and individual delegates who hold authority grants.
The review and maintenance cadence defines when and how the policy updates — not just “annually” but the specific event-based triggers and reconciliation cycles that keep it current between formal reviews. And the compliance and consequences section establishes accountability: what constitutes a violation, how it is investigated, what the range of consequences is, and who owns the process.
Thresholds calibrated once and never revisited become either too permissive or operationally strangling as an organization grows — threshold logic must be anchored to risk exposure, decision volume, and organizational structure, not history.
Threshold design is where most DOA policies fail at scale. An organization sets approval limits at $10,000, $50,000, and $250,000 when it is a $200 million company. Five years later at $2 billion, those same limits route thousands of routine transactions to the CFO and create approval queues that slow every major initiative. The limits weren’t wrong when they were set — they were never updated.
Effective threshold logic is anchored to four factors rather than inherited from the previous version of the policy.
Risk exposure relative to organizational scale. A $50,000 purchase commitment represents 0.025 percent of revenue for a $200 million company and 0.0025 percent for a $2 billion company. Thresholds should be expressed as percentages of relevant reference points — annual revenue, departmental budget, or entity assets — not as fixed dollar amounts that erode in relevance as the organization grows.
Decision frequency and volume. If a particular approval threshold generates hundreds of requests per month, the threshold is too low relative to the organizational level at which it requires approval. Decision volume data from your ERP or procurement system is the most reliable input for threshold calibration. A 2019 McKinsey analysis estimated that ineffective decision-making costs a typical Fortune 500 company more than 530,000 days of managers’ time annually — a significant portion of which is attributable to misaligned approval thresholds.[3]
Regulatory and audit requirements. Some thresholds are not discretionary. SOX Section 404 requirements, banking regulations, and sector-specific rules impose minimum governance levels for specific transaction types. These floor constraints should be documented explicitly in the policy so they are not inadvertently relaxed during future threshold reviews. Protiviti’s 2024 SOX survey identified IT access controls and authorization deficiencies as the number one area for SOX audit findings — reflecting what happens when threshold decisions are made without understanding their compliance implications.[4]
Comparative benchmarking. Peer-organization data is a useful reference for threshold calibration, particularly for organizations in regulated industries where governance norms are relatively consistent. The goal is not to copy competitors’ limits but to identify whether your thresholds are outliers in either direction — unusually permissive in ways that create control exposure, or unusually restrictive in ways that create approval bottlenecks without corresponding risk justification.
One practical approach: build a threshold review into the annual budgeting cycle. When revenue and cost targets are set for the coming year, threshold levels are reviewed against updated organizational scale and decision volume. This converts what is typically an ad hoc process into a scheduled governance event with clear ownership.
For guidance on structuring the matrix that operationalizes these thresholds, see How to Build a Delegation of Authority Matrix.
Effective DOA policies are written for the operator making an approval decision under time pressure, not for the governance committee that approved the document — the gap between those two audiences explains most policy failures.
Policy design principles determine whether a document gets used or ignored. These five principles reflect the consistent differences between DOA policies that function in practice and those that produce audit findings two years after publication.
Principle 1: Write for the operator, not the approver. Most DOA policies are drafted in legal-governance language because that is who authored them. The people who actually need to use the policy — managers making approval decisions under time pressure, on mobile, during a customer negotiation — need clear, direct answers. A McKinsey survey found that 72 percent of senior executives said bad strategic decisions were about as frequent as good ones or were the prevailing norm.[5] Unclear governance is a significant contributing factor. Test your policy by giving it to a new department head and asking them to find the rule that applies to a specific vendor contract. If it takes more than two minutes, rewrite the relevant section.
Principle 2: Make the matrix findable and unambiguous. The policy should specify exactly where the authority matrix lives, how to navigate it, and what to do when a scenario is not clearly covered. If the matrix is in a spreadsheet on a finance server, the policy should say so — and should acknowledge the access and version-control limitations that creates. Ambiguity about where the rules live is one of the most reliable predictors of informal workarounds. West Monroe’s 2026 Speed Wins research found that about one-third of executives and managers cite layers of management approvals as a key cause of slow decisions.[6] When the matrix is hard to find, escalation to senior levels becomes the default, adding approval layers that wouldn’t exist in a well-designed system.
Principle 3: Define temporary coverage as a first-class concept. Every organization has acting roles, interim assignments, parental leave coverage, and vacation backup scenarios. If the policy is silent on these, people default to informal arrangements — email approvals, verbal authorizations, “just this once” exceptions — that never expire and accumulate into a population of phantom delegations that no one formally revoked. Define time-bound delegation explicitly in the policy with three mandatory attributes: a defined start date, a defined end date, and a documented handback process. This single design decision eliminates one of the most consistently cited audit findings in delegation of authority reviews. For the operational mechanics of managing these transitions, see the Authority Change Management Playbook.
Principle 4: Build an operating cadence, not just a review date. “Annual review” is a compliance minimum, not an operating model. Effective policies define a mixed cadence that reflects the real pace of organizational change: event-based updates triggered by role changes, reorganizations, new entity formations, or M&A integration; monthly or quarterly reconciliation of the highest-change authority records; and an annual comprehensive threshold and policy review aligned with the budget cycle. Deloitte’s 2020 research on organizational decision-making found that companies with high organization design maturity — those that systematically maintain decision rights through change — achieved 23 percent greater revenue growth over three years and were three times more likely to develop market-disrupting products and services.[7] The operating cadence is what produces that maturity.
Principle 5: Define consequences before you need them. A policy without an enforcement mechanism is a preference statement. Define what constitutes a violation — unauthorized commitments, bypassed approval requirements, undocumented exceptions — how violations are investigated, the range of consequences from coaching to disciplinary action, and who owns the enforcement process. This is not about punishment. It is about establishing that authority governance is a real organizational commitment rather than a document produced for audit purposes. The Association of Certified Fraud Examiners’ 2024 Report to the Nations found that more than 50 percent of fraud cases occurred because of a lack of internal controls or management override of controls.[8] Explicit consequence frameworks are part of what makes controls real rather than nominal.
The most damaging mistakes are designing the policy in isolation from the matrix, ignoring system enforcement, and treating the initial version as the finished product rather than a foundation to be maintained.
Even well-resourced governance teams repeat the same design errors. Understanding the failure modes in advance makes them avoidable.
Designing the policy without the matrix. Policy and matrix should be developed together, not sequentially. A policy that establishes governance philosophy but doesn’t reference specific matrix rules is too abstract to be actionable. A matrix built before the policy establishes its governing logic tends to reflect the preferences of whoever built it rather than a coherent organizational philosophy. The two artifacts should be co-designed and cross-referenced. For a comparison of how DOA policy logic differs from RACI-based approaches, see DOA vs. Approval Matrix vs. RACI.
Treating policy as a substitute for system enforcement. A policy that specifies who can approve what does not control outcomes unless the systems where actual work happens enforce those rules. If your procurement platform, ERP, or contract lifecycle management system routes approvals differently than the policy specifies, the system wins — not the document. Ponemon Institute research found the average cost of non-compliance at $14.82 million annually, versus $5.47 million for organizations with effective compliance programs — a 2.7x premium directly attributable to this disconnect.[9] For guidance on aligning policy and systems, see Embedding Authority Checks into Workflows.
Over-engineering the first version. Comprehensive DOA policies covering every decision type, every entity, and every edge case are technically impressive and practically unmanageable. The EY study found that most organizations struggle with keeping their DOA policies current — a problem that is dramatically worse when the policy surface area is large.[2] Start with the three to five decision domains that represent the greatest risk exposure — typically capital expenditure, contract commitments, and headcount — and build from there as the program matures and proves its operational value.
Publishing without training. A policy that has been board-approved and legally reviewed but never explained to the managers who must follow it will not change behavior. Training should not be a one-time event — it should be embedded in onboarding, triggered by role changes, and reinforced annually with scenario-based examples drawn from real situations the organization encounters. The EY finding that 36 percent of organizations cite insufficient training as their top DOA challenge reflects how consistently this step is underinvested.[1]
Treating approval limits as the only governance lever. Financial thresholds get most of the policy design attention. Non-financial authority — who can accept risk on behalf of the organization, grant access to sensitive data, approve policy exceptions, or commit the organization to regulatory submissions — is equally important and more frequently undocumented. Organizations that govern financial authority well but leave non-financial authority informal have a systematic control gap that auditors and fraud investigators are well-practiced at finding.
A new or revised DOA policy requires nine sequential actions to move from approved document to operational program — each builds on the last and cannot be safely skipped.
Moving from an approved policy document to a functioning authority program requires deliberate implementation. This checklist covers the sequential steps that convert governance intent into operational reality.
For the signatory-specific elements of policy implementation — maintaining accurate authorized signatory records across banking relationships, regulated counterparties, and legal instruments — see Authorized Signatory Lists Explained.
A well-designed DOA policy produces audit evidence as a byproduct of normal operations — rather than requiring manual reconstruction every time a reviewer asks who approved what and when.
The compliance value of a DOA policy is not the document itself — it is the evidence trail that the policy, when properly implemented, generates continuously. Auditors examining SOX Section 404 controls, internal audit teams reviewing procurement compliance, and regulators examining authorization controls all ask the same core question: can you demonstrate that the right person approved the right action at the right time, with documented authority to do so?
A policy that produces this evidence systematically has four characteristics. Delegations are issued and recorded in a system of record, not stored as email attachments. Approval actions are captured in workflow systems with timestamps and approver identities. Matrix versions are retained with effective dates, so historical approvals can be validated against the rules that applied at the time. And exception approvals are documented and stored alongside the transactions they authorized.
Organizations without these characteristics face a consistent pattern during audits: the auditor asks for evidence of authorization on a transaction from eight months ago, the answer requires reconstructing email chains and calendar records, the reconstruction is incomplete, and what should be a routine audit observation becomes a material control finding. A 2017 Ponemon Institute study found that the cost of non-compliance averages $14.82 million annually — the gap between that figure and the $5.47 million average compliance program cost reflects precisely this kind of downstream audit exposure.[9]
West Monroe’s 2026 research found that 73 percent of C-suite executives say cutting decision time in half would boost revenue by at least 5 percent.[6] The governance investment in a well-designed DOA policy delivers on both sides: faster decisions because rules are clear and trusted, and stronger audit evidence because compliance is built into the process rather than reconstructed after the fact. For a detailed examination of how DOA policy connects to SOX Section 404 requirements specifically, see DOA and SOX/Internal Controls (Q&A).
Aptly connects DOA policy to operational reality — centralizing the authority matrix, tracking delegation issuance and acknowledgment, enforcing time-bound coverage, and generating audit evidence without manual compilation.
Aptly is designed to close the gap between what a DOA policy intends and what an organization can actually demonstrate in practice. The policy sets the rules; Aptly makes them operational and auditable.
Authority matrices managed in Aptly are versioned and timestamped — so auditors can verify the rules that applied on any historical date without requesting documentation reconstruction. Delegation issuance is tracked from creation through formal acknowledgment, with automatic notifications when temporary grants approach their expiry dates. Role changes in connected HRIS systems trigger delegation reviews rather than allowing stale authority to persist indefinitely. And approval actions recorded through Aptly’s workflow integrations create a complete evidence trail as a byproduct of the normal approval process.
Organizations managing authority across multiple entities, jurisdictions, or regulatory frameworks — where maintaining policy consistency across an enterprise-wide matrix is genuinely complex — will find the most immediate value. For organizations earlier in the maturity curve, starting with centralized matrix management and delegation tracking resolves the most common audit exposure before extending to workflow enforcement.
Most effective policies are 10 to 20 pages, plus appendices for the authority matrix and delegation templates. Shorter policies leave too many gaps for interpretation, which teams fill with informal practices that create audit exposure. Longer policies become inaccessible to the managers who need to use them daily. The practical test: can a manager read it in 30 minutes and find the answer to a specific approval question? If not, the policy is either too long or too abstract.
The board or a designated board committee should approve the policy framework — the governance philosophy, scope, and accountability structure. The CFO or General Counsel typically owns the operational content. Day-to-day matrix updates and threshold changes should not require board approval; that level of governance overhead makes the system unresponsive to normal organizational change. The policy should explicitly define which changes require board sign-off and which can be approved at the management level.
The policy framework should be reviewed annually as a minimum. Operational components — matrix thresholds, delegation rules, process ownership — should update on a mixed cadence: event-driven for role changes and reorganizations, quarterly reconciliation of the highest-change authority records, and annual recalibration aligned with budget cycles. The key is designing the cadence into the policy itself so that updates happen as a scheduled governance event rather than a reactive response to audit findings.
The policy establishes governance principles, ownership, scope, and the rules for how authority is managed. The matrix is the operational artifact that maps specific decision types, approval thresholds, and conditions to approver roles. The policy governs the matrix; the matrix operationalizes the policy. An organization can have a strong policy with an outdated matrix, or a detailed matrix with no governing policy — both create compliance and operational problems. The two artifacts must be co-designed and kept in sync.
The most common triggers are: significant organizational restructuring that changes reporting lines or role definitions; new legal entity creation through organic growth or acquisition; material changes in business scale that make existing thresholds misaligned; regulatory updates that impose new authorization requirements; audit or internal review findings that reveal policy gaps; and significant changes to enterprise systems that affect approval routing. The policy should document these triggers explicitly so that responsibility for initiating updates is clear and doesn’t fall through organizational gaps.
Restructuring is one of the highest-risk periods for authority drift. Effective management requires three parallel actions: immediately identifying every individual whose authority is affected by the restructuring; issuing temporary coverage delegations that bridge the transition period with explicit expiry dates; and completing formal matrix updates and delegation reissuance before the temporary coverage expires. A McKinsey analysis found that only 23 percent of reorganizations meet their objectives and improve performance[10] — inadequate governance updates during restructuring are a significant contributing factor. The Authority Change Management Playbook covers the full restructuring protocol.
Yes, and it should be. Separating financial and non-financial authority into distinct policies creates fragmentation that leads to inconsistent governance. Risk acceptance, data access approvals, policy exceptions, regulatory submissions, and hiring decisions all carry organizational exposure that warrants the same disciplined approach as financial commitments. The matrix can separate these decision domains into distinct sections with different threshold structures — they don’t need to be governed by different documents.
Sub-delegation is the act of a delegate passing some or all of their granted authority to another individual. A policy should define whether sub-delegation is permitted by default or requires explicit approval, set a maximum depth for sub-delegation chains, require that sub-delegations be documented in the same system as primary delegations, cap sub-delegated authority at the level of the primary grant, and impose time limits on sub-delegated authority. Undocumented or uncontrolled sub-delegation is one of the most consistent sources of the phantom delegation problem — individuals who nominally no longer hold authority but whose grants were never formally revoked.
The DOA policy governs internal decision rights — who can approve what within the organization. Power of attorney and external signatory authority govern how the organization is legally represented in dealings with third parties: banks, regulators, contractual counterparties, and legal proceedings. These are distinct instruments but must be consistent with each other. An individual authorized to sign contracts internally under the DOA matrix should have corresponding external signatory authority through appropriate legal instruments. For managing the external signatory record specifically, see Authorized Signatory Lists Explained.
The evidence package for demonstrating DOA compliance typically includes: the policy document with its version history and board approval records; the current authority matrix and all prior versions with effective dates; individual delegation letters or system records showing who held what authority and for what period; acknowledgment records showing that delegates received and confirmed their authority; exception approval records; and the results of periodic matrix reconciliation reviews. Organizations subject to SOX, UK Corporate Governance Code Provision 29, or equivalent frameworks need point-in-time evidence — the ability to reconstruct authority as it existed on any specific past date. For the full compliance evidence requirements, see DOA and SOX/Internal Controls (Q&A).
Sources
[1] Ernst & Young LLP and Society for Corporate Governance. “The delegation edge: A guide to successful delegation and authority.” January 2025. ey.com
[2] EY. “Delegation of authority policies can be essential.” January 2025. ey.com
[3] McKinsey & Company. “Decision making in the age of urgency.” April 2019. mckinsey.com
[4] Protiviti. “Empowering the Progress of SOX Innovation with Analytics and Automation.” 2024. protiviti.com
[5] McKinsey & Company. “Untangling your organization’s decision making.” June 2017. mckinsey.com
[6] West Monroe. “Speed Wins: Why Speed Matters.” January 2026. westmonroe.com
[7] Deloitte Insights. “Getting decision rights right.” February 2020. deloitte.com
[8] Association of Certified Fraud Examiners. “Occupational Fraud 2024: A Report to the Nations.” 2024. acfe.com
[9] Ponemon Institute and GlobalSCAPE. “The True Cost of Compliance with Data Protection Regulations.” December 2017. globalscape.com
[10] McKinsey & Company. “Reorganizing to capture maximum value quickly.” February 2018. mckinsey.com
Connect with our team for a discovery session to learn more about how Aptly can help within your organization. If you are already a client and need support, contact us here.
