Stay connected: follow us on LinkedIn and explore more at
www.CherryHillAdvisory.com.
.svg)
Subscribe now to join the Risk Register community:
Nobody in your organization is responsible for removing a control.
That single sentence explains most of what's wrong with most control populations. Adding a control is a documented response to a problem, and it makes whoever proposed it look thorough. Removing one is a judgment call somebody has to defend to an external auditor, and it makes whoever proposed it look like they're cutting corners. So populations move in exactly one direction, year after year, and everybody knows it.
Control rationalization is the structured review that reverses it: eliminating duplication, automating what can be automated, and correcting key control designations, so fewer controls require operating effectiveness testing while the same financial reporting risk stays covered.
It's the largest cost lever most SOX programs have. It's also the one they use least.
Think about where the controls actually came from.
One got added after an audit finding, because adding a control is the fastest way to close a recommendation. Another arrived with a system implementation, when nobody was certain the new automated control fully replaced the manual one, so both stayed and nobody revisited it. Another came from a reorganization, when two groups merged and each brought its own reconciliation to the marriage. And one survives a process change that made it redundant three years ago, because retiring it was never anybody's assigned task.
Over five to ten years the arithmetic gets predictable. The population expands. The financial reporting risk it covers stays roughly where it was. And you pay for the gap between them three separate times.
You pay in operation, because every control consumes process owner time, every period, forever. You pay in testing, because every key control consumes sample selection, evidence collection, execution, and review. And you pay in external audit fees, because every key control in scope is a candidate for auditor testing.
Rationalization is the only lever that hits all three at once. Every other cost conversation in SOX is about rates. This one is about volume.
This distinction gets misunderstood inside finance organizations more often than almost anything else in SOX, and it's the whole game.
Key controls are the ones management relies on to prevent or detect a material misstatement in the financial statements. They require operating effectiveness testing, they get evidenced every period, and they're the population your external auditor scopes against.
Non-key controls still matter. They're still performed, they still protect the business, and nobody's suggesting you stop. They simply aren't the controls management relies on for its assertion about internal control over financial reporting, so they don't carry the same testing burden.
That's worth saying plainly, because the objection in the room is always the same one: making a control non-key doesn't mean the control is unimportant, and it doesn't mean the risk goes uncovered. It means reliance sits where it belongs, and your testing budget follows reliance instead of following habit.
Two patterns turn up constantly in populations that accumulated rather than got designed.
Over-designation happens when controls were marked key defensively, on the theory that a longer key list signals more rigor to an auditor. It doesn't. It signals a scoping decision nobody examined, and it raises cost in a straight line.
Mis-designation is subtler and more expensive. A detective control at the end of a process gets designated key, while the preventive control that actually stops the error sits non-key and untested. Testing the wrong one costs exactly the same and proves considerably less.
Every control in the population gets these three, and the sequence matters.
The first question is whether it's duplicative. Multiple controls covering the same risk and the same assertion is the most common defect in an accumulated population, and it shows up in three recognizable shapes. A manual control and an automated control both addressing the same risk, kept after a system implementation because nobody confirmed the automated one was sufficient. Two controls at different points in the same process, both catching the same error, where the earlier one makes the later one pointless. Or the same control performed at five locations when a centralized control would cover all of them. One well-designed control beats three overlapping ones, in coverage and in cost. Duplication doesn't add assurance, it adds evidence requests.
The second question is whether it can be automated. Manual controls are the most expensive controls to operate and the most expensive to test, and the gap isn't close. A manual control performed daily generates a substantial sample, each item carrying its own evidence request and its own review. An automated control gets tested for its logic and is then carried by your IT general controls for the balance of the period. That's the trade worth naming out loud, though: automation moves your dependence onto ITGCs. Logical access, change management, and computer operations over the relevant systems have to be genuinely reliable, or the automated control isn't reliable either. Automation reduces testing volume. It doesn't remove the foundation underneath it.
The third question is whether the key designation is still right, and it needs the most judgment. For each control still standing, ask whether the risk it covers actually rises to material misstatement potential at your current materiality. Ask whether another control in the population would catch the failure if this one missed it. And ask whether this is genuinely the control management would point to if somebody asked how a specific assertion is covered. Where the first answer is no, or the second is yes, the control may not need to be key. That's a defensible conclusion when it's documented as a conclusion, rather than presented as a reduction.
This is where rationalization efforts fall apart, so it's worth being precise about what actually comes out the other end.
You get five dispositions, not one.
A control you retain is necessary, correctly designated, and correctly designed, and it stays in the testing population unchanged.
A merge consolidates two or more overlapping controls into one, which shrinks the population and requires updated documentation to hold up.
An automation replaces a manual control with a system-enforced one, cutting sample sizes substantially and raising your ITGC dependence in exchange.
A re-designation leaves the control in operation but takes it off the key list, so it comes out of operating effectiveness testing and continues to be performed.
A retirement removes the control from operation entirely, and it's genuinely rare. It's usually a control pointing at a process that no longer exists.
Notice what isn't on that list: reducing coverage. If an exercise leaves a financial reporting risk uncovered, that wasn't rationalization. That was scope reduction wearing a better name, and your external auditor will call it what it is. Full stop.
Rationalization done before the annual scoping decision reduces this year's testing population, this year's evidence requests, and this year's external audit scope. Rationalization done after testing starts reduces essentially nothing, because your samples are already selected and your evidence requests are already sitting in control owners' inboxes.
The practical window is the gap between last year's conclusion and this year's scoping, which for most calendar-year filers means the first quarter. Miss it and you test the unrationalized population one more time, which is about the most avoidable cost in a SOX program.
There's one exception, and it's an important one. For a newly public company, or one coming out of a carve-out, rationalization belongs before the first year of testing. Otherwise the inherited population becomes the baseline you validated, and every future reduction turns into a conversation about why you're deviating from a number you already stood behind. More on first-year programs for newly public companies.
So the question worth asking now, rather than in October: when does your scoping decision actually get made, and who's looking at the population before it does?
A reduction your auditor doesn't accept isn't a reduction. Three things make one defensible.
The first is a complete mapping. Every control in the original population mapped to the risk and assertion it covers, so your auditor can see the coverage rather than take your word for it.
The second is a documented rationale for each disposition. Not a summary saying you removed forty controls. A per-control conclusion explaining why, so the reasoning can be evaluated on its own terms by somebody who wasn't in the room.
The third is advance discussion. Rationalization brought to your auditor before scoping is a conversation. The same work brought during fieldwork is a surprise, and surprises meet resistance regardless of how good the analysis is.
The most common failure is arriving with a smaller number and no coverage map. The auditor's question is never "how many controls did you remove." It's "show me the risk is still covered." Those are completely different conversations, and only one of them ends well.
Starting from the control list instead of the risk list produces a shorter list of the wrong controls. Confirm the risks and assertions the population should cover before you touch the population.
Treating it as a one-time project gives the gain back. Populations start accumulating again the moment the exercise ends, so a rationalization discipline built into annual scoping keeps the benefit while a one-off review loses it inside three years.
Automating without strengthening ITGCs moves risk rather than reducing it. Shifting reliance onto automated controls while change management and access controls over those systems stay weak just relocates the problem somewhere less visible.
Reducing the count without reducing the work is the one that looks best on a slide. Two controls merge into one on paper, both procedures still get performed and evidenced, and you've produced a smaller matrix and an identical bill.
Excluding the process owners costs you the best information in the building. The people performing controls know which ones are redundant, which ones nobody has actually performed in two years, and which ones exist because of a system limitation that got fixed in 2023. Rationalizing from the matrix alone misses every bit of that.
Every population is different, and the patterns are consistent enough to predict.
Look at manual reconciliations kept after an ERP implementation automated the same check. Look at multiple approval layers on the same transaction type, where the lower threshold adds no incremental assurance. Look at location-level controls duplicating something already performed centrally. Look at controls designated key against accounts that stopped being material at your current thresholds. Look at detective controls tested as key while the preventive control that actually mitigates the risk sits untested. And look for controls referencing a report, a system, or a business unit that no longer exists.
That last category is the one that makes people laugh in the room, right before somebody realizes how many years it's been tested.
Rationalization isn't a one-time cleanup, and treating it as one is how populations end up here in the first place. The programs that stay lean are the ones where somebody owns the question every scoping cycle. Build that in now and next year's population is a decision rather than an inheritance.
The cheapest control to test is the one you didn't need. If your population has grown for years without a rationalization pass, there's usually more room in it than anybody expects. Explore our SOX and internal controls practice, or reach out and we'll take a look at what you're carrying.
Cherry Hill Advisory is a global practitioner-built internal audit and risk advisory firm, led by former CAEs and Big Four alumni, delivering co-sourced internal audit, EQA conformance, SOC 2 readiness, ERM, fraud risk management, SOX compliance, cybersecurity, and AI governance. IIA Authorized Licensee. NASBA-accredited CPE provider.
This article is general information, not accounting, legal, or audit advice. Scoping and key control designation decisions depend on facts specific to your company and should be confirmed with your advisors and external auditor.
What is SOX control rationalization?
It's a structured review of a SOX control population that eliminates duplicative controls, identifies manual controls suitable for automation, and corrects key control designations. The objective is to reduce the volume of controls requiring operating effectiveness testing while maintaining full coverage of financial reporting risk.
How much can control rationalization reduce SOX testing cost?
It depends on how much the population has accumulated and how defensively controls were designated. Testing cost scales with the number of key controls, the evidence required per control, and the effort per test, and rationalization reduces all three drivers at once. Populations that have never been rationalized generally hold the most opportunity.
What is the difference between a key and a non-key control?
Key controls are the ones management relies on to prevent or detect a material misstatement, and they require operating effectiveness testing. Non-key controls continue to operate and still matter to the business, but they aren't the basis for management's assertion about internal control over financial reporting, so they don't carry the same testing rigor.
Does reducing the number of key controls increase risk?
Not when it's done properly. Rationalization removes duplication, automates manual controls, and moves reliance onto the control that actually mitigates the risk. If an exercise leaves a financial reporting risk uncovered, that was scope reduction rather than rationalization, and an external auditor will identify it as such.
When should control rationalization be performed?
Before the annual scoping decision, so the reduced population applies to this year's testing and external audit scope. For a newly public company or an entity coming out of a carve-out, it should happen before the first year of testing, so the inherited population doesn't become the validated baseline.
Will our external auditor accept a reduced control population?
Yes, when the reduction is supported by a complete mapping of controls to risks and assertions, a documented rationale for each disposition, and discussion in advance of scoping. Auditors resist reductions presented as a lower number with no coverage map behind them.
How many key controls should a company have?
There's no correct number, and any figure offered as a benchmark should be treated with suspicion. The right size for your population reflects your materiality, process complexity, systems landscape, and reliance decisions. A population that looks large next to a peer's may be right for you, and a population that looks lean may be missing coverage.
Subscribe now to join the Risk Register community:
.png)