Most internal audit and SOX programs carry more controls than they need. The 2021 State of the SOX/Internal Controls Market Survey pegged the average at 300 key controls, with companies above $5 billion in revenue averaging 536 — yet practitioners with comparable revenue bases routinely operate with fewer than 125. The gap is not a measurement error. It is the cost of letting a control universe accumulate by inheritance rather than design.
Risk-based scoping is the discipline that closes that gap. Done well, it strips the control universe down to what actually mitigates material risk, then defends every control that remains with a documented chain of reasoning back to a financial statement assertion, a regulatory requirement, or a strategic risk. Done poorly — or skipped in favor of rolling forward last year’s matrix — it leaves audit teams testing controls nobody can justify, while the risks the program was built to address drift outside the scope.
This guide walks through how to actually reduce a control universe: the conceptual shift from audit universe to risk universe, the mechanics of control rationalization, the IIA’s 2024 Global Internal Audit Standards requirements that now make this non-negotiable, and the practical traps that keep most programs from getting there.
The Audit Universe Problem
Traditional planning starts with an audit universe — a list of every auditable entity, department, process, and system in the organization — and assigns each one a risk score. The plan is built by selecting the highest-scoring entities and auditing them end-to-end on rotation.
The approach has a structural defect. As Norman Marks, the former CAE at Solectron and Tosco, has argued, an audit universe assesses risk at the entity level — a factory, a store, a subsidiary — when the risks that actually threaten enterprise objectives often cut across entities or live above them. In one example, an external IT audit manager at PwC decided to audit systems at more than 6,000 Circle K convenience stores. The enterprise-level risk was low, even if the risk at each store seemed high — there were controls at each store, but better controls at divisional headquarters. The team audited what was in the universe rather than what mattered.
A risk universe inverts the question. Instead of asking which entities are risky, it asks which risks could prevent the organization from meeting its objectives — then identifies which entities, processes, and controls participate in those risks. Bottom-up risk assessment requires a granular view of risks, not the high-level, categorical risks often used in the traditional approach, and benefits from an ongoing risk library that captures considered and emerging risks. The audit plan that emerges is narrower, more specific, and harder to pad.
This shift has consequences for scoping. When the unit of analysis is a risk rather than a department, controls that exist only because they are part of a recurring entity audit lose their justification. The control universe contracts to what is actually doing risk-mitigation work for in-scope risks.
What the 2024 IIA Standards Now Require
The Institute of Internal Auditors’ 2024 Global Internal Audit Standards, effective for quality assessments from January 9, 2025, made the risk-based posture mandatory rather than recommended. Standard 9.4 requires that the internal audit plan must be based on a documented assessment of the organization’s strategies, objectives and risks, performed at least annually. The Considerations for Implementation indicate the internal audit function should only rely on management’s information about risks if it has concluded that the organization’s risk management processes are effective.
That last clause matters. A CAE who imports the ERM team’s risk register without independently assessing whether ERM is functioning is no longer in conformance. Standard 9.5 also requires the CAE to coordinate with internal and external providers of assurance services and consider relying on their work — meaning duplicative coverage between internal audit, SOX, compliance, and second-line risk management is no longer just inefficient, it is a documented standards gap.
The 2024 IPPF additionally introduced Topical Requirements as a mandatory component, with cybersecurity, IT governance, third-party risk, and others receiving baseline criteria for engagement design. Topical Requirements apply when a risk assessment leads to the topic being the subject of an assurance engagement in the internal audit plan, identified during an engagement, or the subject of an engagement request not on the original plan. If a risk-based scope misses a topic that should have been covered — a third-party data flow, a privileged access pathway — the gap is now testable against a published standard.
The practical effect: scoping documentation has to show not just what made it into scope, but why specific risks were excluded and what other assurance providers are covering them.
The Mechanics of Control Rationalization
Reducing a control universe is technical work that runs through three layers: the risk assessment that defines what needs to be controlled, the control mapping that tests whether each existing control actually mitigates an in-scope risk, and the rationalization decisions that retire, consolidate, or replace controls that fail the mapping.
The work usually starts with control bloat diagnosis. The main reason for control bloat is often the failure to conduct a complete and formal SOX risk assessment each year. Even when SOX program leaders have risk assessment expertise, they might skip this crucial step by arguing there were no material changes to the business or control environment in the past year. Rolled-forward assessments preserve every control from the prior cycle by default, including controls added in response to old findings whose underlying risk has since been remediated by other means.
A genuine assessment looks at three things for each control in the existing matrix:
The first is risk linkage. Every key control should be traceable to a specific risk and, in SOX programs, to a financial statement assertion. A control should exist for a reason that can be stated clearly. It should mitigate a defined risk, support a financial statement assertion, satisfy a requirement, or compensate for a known weakness. Controls that cannot pass this test are candidates for removal regardless of how reliably they have been operating.
The second is redundancy. Mature processes accumulate overlapping controls — a manual review, a system edit check, and a downstream reconciliation all addressing the same misstatement risk. The rationalization question is which control gives the strongest assurance at the lowest testing cost. If there are strong information technology controls, one can rely upon automated controls which usually only need to be tested once. Look for processes that can be normalized — if different types of invoices or locations use slightly different processes for approval and recording, work with process owners to create one control that is the same but may be performed by multiple people.
The third is materiality. Only processes that may result in a material misstatement of the financial statements are within SOX scope. If shrinkage is a large operational risk for a retail organization, controls to reduce shrinkage do not belong in SOX scope unless they are themselves a SOX requirement, such as whistleblower controls — as long as the financial statements are reporting the true financial state of the organization, they comply with section 404. Operational controls, project management controls, and good-business-hygiene controls all matter, but they belong in the relevant operational risk program, not the SOX matrix.
A Scoping Decision Framework
The decision logic for whether a control stays, leaves, or merges can be reduced to a small number of repeatable questions. The framework below is what survives across most rationalization methodologies — Baker Tilly, ISACA’s IT Control Optimization guidance, the AuditBoard playbook used at firms like BNY Mellon — once vendor packaging is stripped away.
Fail #3: consolidate or retire the weaker control.
Fail #4: redesign before next testing cycle.
Fail #5: reassign ownership or retire.
The framework is deliberately simple. The hard part is applying it without pulling punches when a control has constituency — the controller who designed it, the auditor who has tested it for five years, the manager who escalated the original finding it was meant to address. Rationalization is as much a political exercise as an analytical one.
Where Programs Get Stuck
Three patterns account for most failed rationalization efforts.
The first is unclear separation between control objectives and control activities. The objective states what the control is meant to achieve. The activity states how that objective is achieved. Keeping these concepts separate improves design and testing, allows the enterprise to rationalize redundant controls, and makes redesign easier when processes or systems change. Programs that document only activities — “Manager X reviews and signs report Y monthly” — cannot tell when two activities serve the same objective and one is redundant. The objective layer is what makes rationalization analytically tractable.
The second is ownership ambiguity. When the central SOX or internal audit team becomes the de facto owner of business controls because they administer the program, the controls drift away from the operations they exist to protect. A central SOX team may maintain the library, testing calendar, and methodology, but it should not become the practical owner of business controls simply because it administers the process. The first line performs and owns, the second line defines standards and monitors, and audit provides independent assurance. Controls without genuine first-line ownership tend to be either ceremonial or wrong, and they resist rationalization because no one outside audit cares enough to defend or retire them.
The third is the assurance overlap problem. Cybersecurity, privacy, vendor risk, model risk, and compliance teams often run their own control libraries and testing programs. Without coordination, the internal audit universe duplicates work that another team is already doing — or worse, leaves gaps because each function assumed the others were covering an area. Establishing a universal risk and controls matrix is foundational for connected risk activities, and the simplest way to start is by identifying all the areas within the business that have documented controls. Internal audit and controls’ history of helping with risk work and testing controls positions them well to help drive connected risk. The 2024 IIA Standards’ coordination requirement (9.5) effectively codifies this as a scoping prerequisite.
What Reduction Looks Like in Practice
The quantitative outcomes vary by starting point. Scott Cronin, Global Head of SOX Compliance & Controls at BNY Mellon, described how centralizing control data allowed his team to link controls to financial statement line items and processes, identify duplicative controls embedded in different parts of the organization, and pursue a notable reduction in key testing controls across the company. Programs that begin with bloated matrices — accumulated over a decade of remediations and acquisitions — sometimes find that 30–40% of their key control population fails the linkage or redundancy tests. Programs that have been periodically rationalized find smaller gains, in the 5–15% range, but with proportionally larger reductions in manual testing effort because automation candidates tend to surface in the same exercise.
The qualitative outcome matters more. A reduced control universe that survives a rigorous risk assessment is defensible in a way that an inherited one is not. The CAE can answer the audit committee’s question about why a particular area was not on the plan. The SOX leader can explain to the external auditor why a control was retired. The risk-based posture stops being a methodology slide and starts being how the program actually thinks.
FAQ
Will reducing key controls trigger external auditor pushback? External auditors generally support rationalization when it follows a documented risk assessment with clear linkage to assertions. Pushback usually comes from skipping the assessment — retiring controls without a defensible rationale — not from the reduction itself. Expanding the percentage of company-tested controls increases efficiency by reducing the volume and cost of auditor testing as well as avoiding controls being tested twice by the company and by the auditors. Bring auditors into the rationalization process early.
How does this interact with SOX Section 404 requirements? Section 404 requires management to assess and certify the effectiveness of internal controls over financial reporting. Rationalization does not weaken that assessment — it sharpens it by ensuring every control retained is one management can stand behind. The risk is in the inverse direction: maintaining controls without a current risk justification creates testing obligations management cannot defend if pressed.
What changes when ERM and internal audit run separate risk universes? The 2024 IIA Standards push toward reconciliation. A connected risk leader will ensure that internal audit has access to ERM’s risk assessment outputs to link audit activities to the business’s top risks. Risk assessments performed assessing an audit universe will also have risk assessments performed by a risk universe reconciled to each other. Separate, unreconciled universes signal a conformance gap under Standard 9.5 and almost guarantee duplicative coverage.
Does this apply outside SOX programs? The same logic applies to operational, IT, compliance, and third-party risk programs. The vocabulary changes — “key risk” rather than “financial statement assertion,” “regulatory citation” rather than “materiality threshold” — but the rationalization decision tree holds. Any control library that has not been re-justified against current risks in the past 18 months is a rationalization candidate.
The Stance
The control universe is not a neutral inventory. It is a record of what the program decided to care about, and like any record, it accumulates errors, duplications, and obsolete entries faster than it deletes them. Risk-based scoping is the correction mechanism. Programs that run the correction annually — with a real risk assessment, defensible linkage, and the willingness to retire what no longer earns its place — keep the universe honest. Programs that don’t carry the past forward indefinitely, paying testing costs in dollars and audit fatigue in stakeholder credibility.
The 2024 IIA Standards have made the bare minimum visible. Anything beyond it — the actual reduction — still depends on the willingness of audit leadership to defend smaller, sharper scopes against the institutional pull toward “we’ve always tested it.” That is where reduction is won or lost.
