
October 29, 2026 • 14 min read
How to build a risk-based audit plan
Most teams build audit plans around last year’s schedule. But that approach can leave teams misaligned with IIA Standards before fieldwork even begins.
Cyclical planning relies on lagging indicators. Past findings, prior audit coverage cycles, and last year’s assumptions have traditionally guided resource allocation. That approach may work in a stable environment, but when the business adopts AI tools, enters new markets, changes vendors, or restructures operations, the system can quickly fall out of step with its risk profile.
Risk-based audit planning starts with current residual risk. It asks three critical questions: Where is exposure highest today? Where is assurance coverage weakest? Where has the business changed faster than the plan? Internal audit then allocates resources to the areas where the gap between current risk and existing assurance is widest.
The result is a documented, prioritized audit schedule tied to assessed risks, with resource allocations that can be defended to the audit committee. The IIA Global Internal Audit Standards formalize this expectation: Standard 9.4 requires the chief audit executive to base the internal audit plan on a “documented assessment of the organization’s strategies, objectives, and risk.” Audit leaders must also consider coverage of information technology governance, fraud risk, and the effectiveness of compliance and ethics programs.
This article walks through how to build a risk-based audit plan: define the risk universe, score and prioritize risk, map existing assurance, and update the plan as conditions change.
Building the risk universe
A risk universe is the starting inventory for a risk-based audit plan. It captures the risks the organization faces, mapped to business processes, operating units, or strategic objectives. Without a risk universe established the planning process defaults to limited, pre-existing knowledge or specific management concerns.
The risk universe draws from multiple sources:
- Enterprise risk registers maintained by the risk management function
- Regulatory and compliance requirements specific to the organization’s industry and geography
- Prior audit findings, particularly repeat findings or areas where remediation stalled
- Management self-assessments and control certifications
- External inputs such as industry loss data, peer benchmarking, and regulatory enforcement trends
- Emerging risk scans covering new technology adoption, market shifts, or geopolitical exposure
The organization of the risk universe matters as much as its content. For example, structuring it around the org chart, with one entry per department or business unit, is a common failure point, as it leads to plans built around functions like “audit procurement” or “audit IT” instead of risk exposures like third-party payment controls, privileged access, or AI model governance. When the universe mirrors reporting structure, cross-functional risks disappear from the map. A stronger approach for building a risk universe is to map it to business processes or risk themes rather than to team structure. Fraud risk in accounts payable, for example, cuts across procurement, finance, and IT. An org-chart view, on the other hand, would assign it to one owner. A process-based view keeps the full exposure visible.
The risk universe should not stay static. New AI deployments, vendor relationships, system implementations, and market expansion all change what belongs in scope. In addition to annual reviews, a process for how emerging risks get added between formal planning cycles must be defined — otherwise, the universe goes stale before the plan is even approved.
Assessing and scoring risks
Once the risk universe is built, each entry needs to be assessed consistently. The goal is to turn a list of risks into a prioritized view that shows where audit attention will be required.
Most risk-based audit plans score risks against a standard set of factors:
- Likelihood of the risk materializing, based on historical frequency and current conditions
- Impact on financial results, operations, regulatory standing, or reputation
- Velocity, or how quickly the risk could escalate from early warning to material event
- Control maturity, meaning how well-established and tested the existing controls are
- Time since last audit, which accounts for assurance decay in areas that have not been reviewed recently
These factors are usually combined in a weighted scoring model. An organization with significant regulatory exposure may weigh impact and compliance factors more heavily, while one undergoing rapid digital transformation may give greater weight to velocity and control maturity. This should reflect the organization’s own risk appetite and the audit committee’s stated priorities rather than a generic template.
A scored risk universe gives the context needed to determine which engagement makes the final plan. For example, a quantitative score might rank two risks equally, but one sits in an area the board has flagged as a strategic concern while the other has strong second-line oversight. A scoring model also provides a defensible answer grounded in assessed risk rather than precedent or preference.
For organizations evaluating how scoring methodology fits into broader risk-based auditing approaches, they should consider how the choice of scoring model shapes not only which engagements appear on the plan, but how each engagement is scoped and staffed.
The scoring approach also shapes more than the plan itself. It influences how engagements are scoped, how much coverage is needed, and whether the team has the right skills to execute them well.
Mapping assurance coverage
A scored risk universe tells the audit team where risk is highest. However, it does not tell them where assurance is already in place. Before finalizing the plan, the team needs a clear view of what other functions are already covering.
Internal audit is rarely the only source of assurance over a given risk. Other functions are already testing, monitoring, or reviewing many of the same areas:
- Compliance teams run their own testing programs
- Risk management monitors key risk indicators
- Quality assurance reviews operational processes
- External auditors test financial controls
- Regulatory examiners review specific domains on their own cycles
Before the plan is locked, the team should map assurance coverage across the risk universe. For each risk, documentation must show who is providing assurance, how independent that coverage is, how deep it goes, and how recently it was performed.
A practical assurance map tracks three types of coverage per risk:
- First-line coverage: management controls, self-assessments, and operational monitoring owned by the business
- Second-line coverage: oversight functions such as compliance, risk management, and IT security that test or monitor controls independently of the business
- Third-line coverage: internal audit engagements, external audit procedures, and regulatory examinations
Risks with strong, recent, and genuinely independent coverage across multiple lines may rank lower on the plan. Those with limited coverage move up, especially when only the first line is active or when second-line oversight is high-level rather than supported by testing.
IIA Standard 9.5 formalizes this expectation. It requires the CAE to coordinate with second-line functions and external assurance providers to identify coverage gaps and reduce duplication. The assurance map is the tool that turns conversations into documented coordination.
It also makes the plan easier to defend. When the committee asks why one area is on the plan, and another is not, the answer should point to two features: current risk and the absence of sufficient independent assurance.
Technology governance is a common example. Many organizations have mature oversight for financial controls or regulatory compliance, but much sparser independent coverage over AI adoption, data governance, identity and access management, or IT change management. Mapping assurance across the full universe makes those gaps visible before they show up as findings or incidents outside of internal audit.
Directing resources to the highest-risk gaps
A scored risk universe and a completed assurance map give the audit team two inputs: where exposure is highest and where independent coverage is thinnest. The plan should concentrate on where these two conditions meet.
High-residual-risk areas with limited second- or third-line assurance take priority in the plan. Lower-risk areas with strong existing coverage move to a reserve list or a longer rotation cycle. Areas where second-line functions already run robust, independent testing may not need an internal audit engagement at all during the current period.
The plan also has to be executable. A risk-aligned plan on paper still fails if it assumes time, skills, or access that the team does not actually have. That means accounting for:
- Available audit hours after administrative time, training, and carryover work
- Specialist skills required for technical engagements such as IT audits, data analytics, or AI governance reviews
- Geographic and operational access, particularly for organizations with distributed operations or international entities
- Co-sourcing or guest auditor capacity for engagements that exceed in-house expertise
Planning against real capacity forces trade-offs early, where the team can defer work deliberately instead of discovering halfway through the year that the schedule was never realistic.
For each engagement, the final plan should document the scope, estimated hours, timing, required skills, and the risk rationale for why it made the cut. When a board member asks why the team is auditing vendor payment controls instead of IT change management, the answer should trace back to assessed risk, available assurance, and capacity.
Keeping the plan current
A risk-based audit plan that gets approved in January and runs unchanged through December has the same problem as the rotation-based plan it replaced. By Q3, the organization may have launched a new product line, onboarded a major vendor, or faced a regulatory action that reshuffles risk priorities entirely.
The plan needs a built-in way to address change. In practice, that means three things:
- Scheduled reassessment. Review the risk universe and assurance map at a defined interval, typically quarterly. Update risk scores based on new information: control failures, audit findings from completed engagements, shifts in the regulatory environment, or changes in business strategy. Engagements added or deferred as a result get documented with the same risk linkage as the original plan.
- Trigger-based amendments. Some changes do not wait for a quarterly cycle. A material control failure, a cybersecurity incident, an acquisition, or a sudden regulatory development may require immediate plan adjustment. Define in advance what types of events trigger a plan review, and who has authority to approve amendments between scheduled reassessments.
- A formal deferral process. When new engagements enter the plan mid-year, priorities must be reshuffled. Without a documented deferral process, lower-priority engagements drop off the schedule. A formal process captures what was deferred, the risk rationale behind the deferral, and when it can be re-added to the plan.
When conditions change, but the plan does not, the team ends up auditing areas that no longer represent the highest risk while emerging exposures go unexamined. A dynamic plan is evidence that the team is responding to actual conditions rather than defending a static document.
You may also like to read


Why “Trusted Advisor” Will Become Internal Audit’s Entire Value Proposition: Excerpt from Richard Chambers’ Latest Book

FJ Management advances its agentic audit strategy with Optro

How AI-guided evidence coordination gets auditors to testing faster

Why “Trusted Advisor” Will Become Internal Audit’s Entire Value Proposition: Excerpt from Richard Chambers’ Latest Book

FJ Management advances its agentic audit strategy with Optro
Discover why industry leaders choose Optro
SCHEDULE A DEMO



