Somewhere between “we all sit in one room and just know what’s going on” and “we need a compliance function,” most growing organizations pass through a dangerous middle stretch. Headcount has doubled, a few departments now run their own budgets, and the founder or ops lead who used to catch every mistake by osmosis can no longer see everything. This is exactly when controls either get added deliberately — or get bolted on reactively after something breaks. The second path is more common, and it’s expensive: rushed controls after an incident tend to be heavier, more bureaucratic, and worse targeted than controls added on purpose, ahead of time.
Control design isn’t about installing a rulebook. It’s about matching a small number of checks to the specific points where money, decisions, or commitments could go wrong — and doing it in a sequence that tracks how the organization is actually growing, not in one big compliance sprint.
Key Takeaways
- Controls should be added in response to specific risk triggers (headcount, spend thresholds, new locations, new systems) — not on a fixed calendar or because a template says so.
- The highest-value early controls are almost always around cash, vendor payments, and system access — not around low-risk day-to-day decisions.
- Every control needs an owner, a trigger condition, and a cost in time — if you can’t name all three, it isn’t ready to implement.
- Segregation of duties is the single most under-priced control in small and mid-sized organizations, and the cheapest to fix early.
- Over-controlling is a real failure mode: too many checks too early slows decisions and trains people to route around the process.
Why Control Design Has a Sequence, Not a Checklist
A 12-person company and a 120-person company face different risks, and copying a control framework built for the larger one onto the smaller one wastes effort on problems that don’t exist yet — while possibly missing the ones that do. The right way to think about control design is as a response to specific triggers in the business, not a maturity checklist to complete in order.
Common triggers that should prompt a control review:
- A second person is now authorized to approve payments or contracts.
- The organization opens a new bank account, credit line, or expense category.
- A new office, region, or remote team is added, especially across a currency or regulatory boundary.
- Headcount in finance, procurement, or operations roughly doubles.
- A new system (ERP, CRM, expense tool) is introduced that changes who can see or edit what.
- The organization takes on outside investors, a board, or lending covenants that require reporting discipline.
Each of these events changes who can do what to the organization’s money, data, or commitments — and that’s the actual definition of risk that controls should track. If none of these things have changed in the last two quarters, you probably don’t need new controls, regardless of what a generic framework recommends.
The First Controls to Add — Before Anything Else
Not all controls are equally valuable early on. A handful cover most of the real exposure in a growing organization, and they should be in place well before anything more elaborate:
- Segregation of duties on payments. The person who initiates a payment should not be the same person who approves it. This is the single most common control gap in small organizations, and it’s the one most often exploited — whether through fraud or simple error.
- A defined approval threshold ladder. Set dollar thresholds where a second approver is required, and where it escalates further (e.g., manager approval above $1,000, director above $10,000, two signatures above $50,000). Keep it to two or three tiers — more than that slows things down without adding real protection.
- Vendor and bank detail change controls. Any change to a vendor’s banking details should require verification through a second channel (a phone call to a known contact, not just an email reply). This single control stops the most common form of payment fraud.
- System access reviews. Know who has admin rights to your financial systems, banking portals, and payroll, and review that list quarterly. Access accumulates as people change roles; it rarely gets removed without a deliberate review.
- Basic reconciliation cadence. Bank and credit card reconciliations happen monthly, by someone other than the person recording the transactions.
These five cost very little to implement and catch the overwhelming majority of the risk that shows up in growing organizations. Everything past this point is refinement, not foundation.
What to Add as You Scale — And What to Resist Adding
As the organization grows past the foundational stage, the temptation is to keep adding controls indefinitely. Resist that. The goal is proportionality: each new control should map to a specific, named risk that has actually increased, not to a general sense that “we should be more buttoned-up now.”
Controls worth adding as headcount and complexity grow:
- Budget variance review. Once department heads own budgets, a monthly variance review (actual vs. planned, with a required explanation above a set threshold) keeps spending visible without requiring pre-approval for every line item.
- Contract review thresholds. Contracts above a certain value or duration route through a second reviewer (legal, finance, or both) before signature.
- Expense policy with spot audits. Rather than reviewing every expense report, define a policy and audit a random sample each month. This scales far better than 100% review.
- Change management for financial systems. Any change to chart of accounts structure, approval workflows, or integrations gets logged and reviewed, so system changes don’t quietly create new gaps.
Controls to actively resist adding too early: multi-level sign-off on routine low-dollar purchases, mandatory committee review for operational decisions, and detailed documentation requirements for reversible, low-risk actions. These feel responsible but mostly train competent people to find workarounds — which is worse than having no control at all, because now there’s a false sense of coverage.
Assigning Ownership: The Part Most Organizations Skip
A control without a named owner is a control that will quietly stop happening within two quarters. For every control on your list, you should be able to answer three questions without hesitation:
- Who owns it? Not “finance” — a specific role or person.
- What triggers it? A calendar date, a dollar threshold, a specific event — not “as needed.”
- What does it cost? An honest estimate of the time it takes each time it runs, so you can weigh it against the risk it’s covering.
If you can’t answer all three for a proposed control, it isn’t ready to implement — it’s still an idea. Write it down, assign a draft owner, and test it for one cycle before calling it a real control. This also gives you a natural forcing function to retire controls that turn out not to be worth their cost, which is just as important as adding the right ones.
Frequently Asked Questions
How many controls should a 30-person organization have?
There’s no fixed number — it depends on what the organization handles (cash volume, number of systems, regulatory exposure). As a rough gut check, if you can’t list your active controls from memory in under a minute, you likely have too many, or too many that lack a clear owner and trigger.
Who should own control design in a company with no dedicated risk or compliance function?
Usually finance or operations leadership, working with whoever owns each process area. Control design doesn’t require a formal risk title — it requires someone accountable for reviewing the trigger list periodically and making the call on what to add or retire.
What’s the biggest control mistake growing organizations make?
Adding controls reactively, right after an incident, under pressure. These tend to be broad, heavy, and aimed at preventing the exact last problem rather than the range of problems the organization is actually exposed to. Deliberate, trigger-based design produces lighter, better-targeted controls.
Do controls need to be formally documented to count?
Yes, at least briefly. A control that exists only as an informal habit disappears the moment the person doing it leaves or gets busy. A short written description — what it is, who owns it, what triggers it — is enough; it doesn’t need to be a formal policy manual to be durable.