A repeatable change management workflow for authority: requests, approvals, temporary coverage, versioning, communications, and audit evidence.
Before managing changes, you need a solid policy foundation. See Writing a DOA Policy People Will Actually Follow for that starting point.
Definition: Authority change management is the controlled process by which an organization requests, reviews, approves, publishes, and communicates changes to decision rights, approval limits, and delegated authority — ensuring that authority records remain accurate, versioned, and audit-ready through every organizational shift.
The most important part of authority management is not the initial design. It's what happens after the first re-org, the first acquisition, and the first urgent request for "just temporary coverage." West Monroe's 2026 Speed Wins research found that each request for additional analysis adds an average of three weeks of delay. Authority changes follow the same pattern: when the change process is slow or unclear, teams create workarounds that bypass governance entirely.
A good authority change process should make it easy to answer three questions:
If you can reliably answer those, you're already ahead of most organizations. The EY/Society for Corporate Governance study found that 90 percent of companies have DOA policies but struggle with enforcement and updates — and ineffective change management is the primary reason authority programs degrade over time.
| Step | Purpose | Key Actions | Evidence Produced |
|---|---|---|---|
| 1. Request | Capture the change with context | Scope, role, effective dates, justification, systems impacted | Standardized change request record |
| 2. Impact check | Validate risk before approval | SoD check, risk assessment, consistency with comparable roles | Impact assessment with flags |
| 3. Approve | Right stakeholders for the risk level | Routine: matrix owner. Material: finance/risk/legal leadership | Approval record with identity and timestamp |
| 4. Publish | Make the change official | Version the update, set effective date, retire old version | Versioned authority record with effective dates |
| 5. Notify | Ensure affected parties know | Notify delegate, manager, process owners, system owners | Notification and acknowledgment records |
| 6. Enforce | Update downstream systems | Align ERP, procurement, CLM, treasury, identity systems | System configuration change records |
| 7. Retire | Expire temporary authority | Auto-expiry for time-bound grants, revert to standard mapping | Expiry record and reversion confirmation |
If any step is missing, you'll be reconstructing history later. McKinsey's research on organizational decision-making found that the most effective organizations delegate decisions with explicit clarity — and that clarity requires a controlled change process, not just an initial delegation.
Require every authority change request to include: what decision rights are being changed, which role/person is gaining or losing authority, effective date and expiration date if applicable, business justification, risk flags (e.g., segregation of duties concerns), and systems impacted. The form can be simple. The consistency is what matters.
Before approval, validate: Does this change create a segregation of duties conflict? Does it increase risk without a compensating control? Is the authority consistent with comparable roles and regions? Do downstream systems need updates to enforce the change?
Our recommendation: Build the SoD and risk check into the request workflow itself, not as a separate manual step. When the check happens automatically at request time, conflicts are caught before approval — not after an auditor discovers them months later.
Match the approvers to the risk: routine changes within defined limits need the matrix owner plus business owner. Material authority increases need finance leadership plus risk or legal. Changes affecting regulated processes need the compliance or control owner. The point is not to create a committee; it's to ensure the right people see the change.
Two rules prevent confusion: every change has an effective date (even if it's "effective immediately," record it), and old versions don't disappear — they're retired, not deleted. Version history is what allows "as-of" answers later.
DOA changes fail silently when people don't know they happened. At minimum, notify the new delegate, their manager, the process owners who route approvals, and the system owners who enforce workflow controls. In mature programs, organizations also require acknowledgment for high-impact authority grants.
Authority is only real if systems and workflows align. Common enforcement points include ERP approval rules, procurement workflows, CLM signature and clause approval rules, treasury and banking entitlements, and identity/access management for privileged actions. If enforcement isn't updated, you'll either over-escalate or under-control.
Temporary authority should expire without anyone needing to remember it. Issue the delegation with an end date, schedule notifications before expiry, and automatically revert to the standard authority mapping when the end date passes. This is one of the biggest levers for reducing authority drift over time.
Aptly supports controlled change management: version history, effective dates, time-bound delegations, tracked issuance, and audit-ready logs. When paired with integrations, it also helps ensure that systems reflect the same authority truth — which is where drift typically starts.
Routine changes (within established parameters) should be processed within 1–2 business days. Material changes requiring additional review typically take 3–5 business days. Emergency coverage should be grantable same-day with expedited approval. If your average turnaround exceeds a week, teams will create workarounds.
The most common triggers are role changes, promotions, terminations, re-orgs, new entity or bank account creation, M&A integration, planned absences requiring temporary coverage, and periodic threshold recalibration. Event-driven triggers should be automated where possible through HRIS integration.
Require an explicit end date on every temporary grant. Schedule notifications before expiry. Implement automatic reversion when the end date passes. Report on temporary coverage exceeding defined thresholds (e.g., 90 days) as a governance metric. Without these controls, temporary authority is the single largest source of authority drift.
The approval chain should reflect the risk level of the change. Routine adjustments within established parameters need the matrix owner and direct business owner. Material authority increases need finance or risk leadership. Changes affecting regulated processes need the compliance or control function. The goal is proportionate governance, not blanket committee review.
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.
