Delegation of authority: who can approve what, on one page

Every small team runs on one of two failed defaults. Default one: everything escalates to the owner, so a $79 software renewal waits three days for a signature while the trial expires, and nothing moves while he sleeps — including, if you run agents of your own, every automation you built to move things while you sleep. Default two: the blank check, where a $9/month trial becomes a $2,000/year line item that nobody remembers approving and a former employee still has domain admin because "someone set it up in March." A delegation of authority (DoA) table is the middle path: one page that says, for the five kinds of decisions that actually happen in a ten-person company, who decides, up to what number, and what evidence the decision leaves behind. It is written on a calm Tuesday so it can be applied on the stressful one. This page is the template, in the order you should build it.

1. The five rows that cover ninety percent of decisions

One-time money. Software purchases, hardware, contractors, the surprise invoice. The most expensive decision type to leave undefined, because it's the one a busy week quietly answers with "just put it on the card."
Recurring money. Subscriptions, retainers, monthly SaaS seats. This row exists because recurring spend is forever money: the $49/month tool that survives four years is $2,352, and it was approved by nobody in particular. Treat every new recurring charge as owner-tier regardless of the amount — it's the same sprawl logic as the SaaS sprawl audit, applied at the front door instead of during the cleanup.
Access and admin rights. Who can grant the keys: standard tooling for a new hire is different from domain admin, break-glass credentials, or a payment-method change. This is the row that keeps the quarterly access review short, because every grant traces to a named approver instead of a shrug.
External commitments. Contracts, security questionnaires, anything customer-facing with your name on it. These bind the company, and the signature discipline lives in the vendor contract checklist: one signer, one folder.
Incidents. The 2 a.m. spend that unblocks a recovery. Defined at noon so the night shift doesn't have to text the owner to buy back the business — the same "decided in advance" logic as the runbook template.

2. The money column: numbers, not adjectives

A threshold is a dollar figure with a name attached, or it is decoration. "Small purchases can be approved by managers" is not a policy; "$200–$2,000: the budget owner, evidenced by a ticket number" is. Numbers are what make the table survivable by anyone who isn't the owner, and what make it auditable by anyone who is.
A working starter set for a ten-person team: under $200 — any team member, receipt to the shared folder, monthly spot-check; $200–$2,000 — the named budget owner; over $2,000 — owner signature; any new recurring charge — owner, always, even $9/month, because the amount is not the point, the forever is.
Review the numbers annually or they erode into theater. Inflation, team growth, and habit all push real decisions past thresholds that no longer match reality — and once people routinely break a threshold "because it's obviously fine," the table trains everyone to ignore tables. Put the review in the calendar next to the annual security review, adjust the numbers, re-sign the page. One line in the meeting notes is the whole ceremony.

3. The access column: who can grant the keys

The standard new-hire stack is a manager decision, executed from a checklist. Email, chat, the standard tool set — the hiring manager approves, provisioning runs off the new-hire onboarding checklist. This is deliberately fast: you are not protecting the company from a new designer having Figma.
Admin, break-glass, and payment rails are owner decisions, full stop. Domain admin, the password vault's admin group, MFA resets for admins, any change to the bank account or card on file. These are the credentials an attacker wants and the ones a mistake costs the most — they sit in the same tier as the break-glass accounts: few holders, logged grants, named approver on every one.
Offboarding anyone can trigger; the owner sees the log. Removing access on a departure should never wait for a signature — the checklist runs the same day, and the DoA row says "anyone may execute, owner receives the completion log." Speed on removal, ceremony on grant: that asymmetry is the whole trick, and it's the same one the offboarding checklist runs on.

4. The evidence column: approvals you can audit

Every row names where the approval lives. A ticket comment, a signed PDF in the contracts folder, a pinned message in the approvals channel — the place matters less than the fact that it exists and is the same place every time. An approval that lives in a text message is an approval that doesn't exist in six months, which is the same "a place, not a person" rule the license register applies to keys.
The traceability test is one question: "who approved this, and where would I look?" Pick three real decisions from last month — a purchase, a grant, a contract — and trace each to a row and an artifact. If any of the three dead-ends, the table has a hole; fix the row, not the retrospective.
This column is what the outsiders read. The insurer's questionnaire, the customer's security questionnaire, and the cyber insurance checklist all ask some version of "who can approve spend and access?" The evidence column turns the answer from an essay into a link.

5. Deputies: the vacation problem, solved at noon

Every approver row gets a named deputy. Not "someone senior" — a name. The table's first real test is not a purchase, it's the owner being unreachable for a day while a decision ripens, and a row without a deputy fails that test by design.
The deputy line has its own limits, written in the row. A sensible pattern: the deputy may approve one-time spend up to a lower cap, may never approve new recurring charges, admin grants, or contract signatures, and logs every decision in the same evidence column. Narrow in scope, unambiguous in wording.
Deputy authority can be time-boxed without ceremony. "While I'm on the plane" is a valid activation if the deputy line already exists on paper. What kills small teams is not the wrong person deciding — it's the right person being the only person who can, which is one careful bus factor away from the first-week runbook's whole argument about inheriting the keys.

6. Incidents: the 2 a.m. exception, defined at noon

The incident commander gets a spend cap, not a phone tree. Write it down: "to restore service, the IC may spend up to $500 without asking — the vendor's urgent support tier, a spare drive, an hour of a contractor's time." This is the difference between a ten-minute recovery and a two-hour one where the senior person is negotiating with a payment page at 2 a.m.
Everything else follows the emergency-change path: act to restore, then ratify in writing within 24 hours — the same after-action discipline the maintenance window policy applies to emergency patches. Ratification is not bureaucracy; it's how the exception teaches the table where its thresholds are wrong.
Restoring service and negotiating are different authorities. The IC can buy the backup that ends the outage; the decision to pay an extortion demand, sign anything, or talk to the attacker stays with the owner — see the short list below.

7. What never delegates

Bank and payment-method changes, always the owner. Not the deputy, not "finance," the owner — because this is the one row where a single approved fraud costs the most and reverses the slowest.
Break-glass credential knowledge and legal signatures. The break-glass envelope has named holders and that list is short by design; contracts get one signer per the vendor contract checklist, with the lawyer rule ($10k+) untouched. Delegation multiplies speed at the edges by concentrating the pointy end deliberately.
People decisions and the ransom question. Terminations, compensation, and any decision to pay an extortion demand stay at the top — these are the decisions where being wrong is expensive in ways a table cannot amortize.

8. Installing it in one afternoon

One page, one table, one signature. Five rows, dollar figures, deputy names, evidence locations. The owner signs it; it gets pinned in the wiki next to the first-week runbook so the next admin inherits the authority map along with the passwords. A DoA table that lives in someone's head is the blank check with extra steps.
The done-signals are behavioral, not documentary. Anyone can answer "can I buy this / can I grant this" in under sixty seconds without pinging a human; the owner's approval queue fits on one screen; and the last month's decisions all trace to a row. When those three are true, the table is working. When the first one isn't, the table is decoration and people are back to asking forgiveness.
Calendar the annual re-sign and fold it into the annual review: thresholds moved, deputies confirmed, rows for things that became a thing this year (your first AI agent's spend, for instance — the agent ops playbook has opinions on who an agent reports to, and the DoA row is where that authority is written down).

Small-team honesty note: you do not need the corporate forty-page DoA policy with a signature matrix and twelve approval tiers — that's for companies where "who approved this?" is a deposition question. Ten people need one table, five rows, numbers with dollar signs, a deputy per row, and an emergency clause. The trap this page prevents is symmetric: the owner-as-bottleneck, where every $79 decision waits for a signature and nothing moves overnight (including your agents, which will wait politely and infinitely at exactly that gate), and the blank check, where nobody remembers approving the $2,000/year thing and the quarterly review finds admin grants with no mother or father. Five rows beats both failures. Write it on a calm Tuesday.