August 6, 2026

What is audit risk? How to assess and mitigate the part you control

Amanda Waldmann

Increasing trust with AI for audit and advisory firms.

Key insights

Detection risk is the only piece of the audit risk model you actually control. Inherent and control risk belong to the client; your procedures are the only lever that moves.
Skip control testing and control risk sits at maximum under SAS 145. Your inherent risk assessment becomes the risk of material misstatement assessment, with no buffer between an under-scoped plan and an inspection finding.
Full-population testing under the PCAOB's 2024 amendments drops sampling risk to zero, but detection risk remains. Test 100% of the wrong criteria and you've bought a clean-looking file that answers the wrong question.

The audit risk model gets taught as a formula: audit risk is inherent risk times control risk times detection risk, or AR = IR × CR × DR. In practice, no partner picks a decimal for management bias, and no manager runs that multiplication on the planning memo. The model forces a sequence of judgments: where misstatements are most likely, whether the client's controls will catch them, and how much evidence your procedures have to produce in response.

Two recent changes raised the bar on that sequence. SAS 145 now makes you assess inherent risk and control risk separately, and it sets control risk at maximum whenever you don't test controls. The PCAOB's 2024 amendments on technology-assisted analysis spelled out what you actually get, as evidence, from testing a whole population instead of a sample. Neither replaces the judgment underneath. Both change what a defensible plan and file have to look like. This article covers how the model orders those judgments, what to do when the assessment shifts mid-engagement, and how full-population testing reshapes the detection-risk conversation.

How the audit risk model works: inherent, control, and detection risk

Audit risk is the risk you give a clean opinion on financial statements that are materially misstated. The audit risk standard splits that risk in two:

The risk of material misstatement (RMM): inherent risk and control risk together, both of which come from the client.
Detection risk: the chance your own procedures miss a misstatement that's really there.

You build RMM in a set order:

Assess inherent risk at the assertion level, before you look at any controls.
Assess control risk: it stays at maximum unless you test controls and they hold up.
Combine the two, and that's your RMM.

Detection risk is then whatever's left. Your total acceptable audit risk is fixed and low, so the more misstatement risk the client brings, the less room your own procedures have to miss anything. That's the inverse that runs the plan: the higher the RMM, the lower the detection risk you can accept, and the more your testing has to catch on its own.

The detection risk you're left with drives everything else: the nature, timing, and extent of your substantive work. Take a partner reviewing a plan for a high-RMM revenue assertion. They should expect a heavier response: confirmations or reperformance rather than inspection alone, cutoff testing at year-end rather than a rolled-forward interim window, and a bigger sample or full-population test rather than last year's default. Every one of those levers costs hours. So the RMM assessment isn't box-ticking on a planning memo. It sizes the whole engagement.

Inherent risk and control risk come from the client

Inherent risk and control risk exist whether or not you show up to audit. Inherent risk is how prone an assertion is to misstatement before any controls kick in. Control risk is the chance the company's own controls fail to catch or prevent a misstatement in time. Both come from the client: their business, their environment, how they designed their controls. You read them off the evidence in front of you. Nothing you do later changes them, and that's exactly what sets them apart from detection risk, the one piece you own.

SAS 145 made this sharper. It now wants separate assessments for inherent and control risk, with a hard default: if you're not testing whether controls actually operate, control risk goes to maximum. Plenty of mid-market engagements run fully substantive, with no control testing at all, so control risk is maxed from the start. That leaves inherent risk carrying the entire RMM on its own. Get the inherent call wrong and there's nothing on the control side to offset it. Pitch it too high and you over-audit everything it touches. Pitch it too low and your procedures won't get you enough evidence.

Assessing the two separately has an upside, though. It lets you be honest about the assertions that don't need much. Rate inherent risk genuinely low where it really is low, and you free up hours. Default everything to a blanket "moderate" and you lose that, spending hours where they buy you nothing.

How to revise your risk assessment mid-engagement

Sometimes new evidence blows up the basis for your original plan. When it does, you go back and reassess under the PCAOB risk assessment standard, then change your procedures or add new ones. The AICPA's risk assessment standard treats this as iterative for both inherent and control risk. And you run a stand-back check while you're at it: did you actually catch every significant class of transactions, balance, and disclosure?

This is exactly what inspectors hunt for. A confirmation comes back strange, a walkthrough turns up a gap, an estimate's assumptions look aggressive. The manager drops the exception in the disposition column, closes the review note, and moves on. The finding isn't the exception itself. It's the failure to loop back and ask whether the sample size, the procedure, or the accounts you scoped still make sense given what that exception just told you.

Document the change the same way you documented the original call: as a judgment about the entity. The AICPA-CIMA discussion makes the point that you should be able to support an inherent risk assessment without referencing controls or your own procedures. It also notes that some peer reviewers are pushing documentation demands past what the standard actually requires. Wherever your reviewer sits in that argument, an inherent risk writeup that leans on "controls are strong here" is going to draw a comment.

How full-population testing changes detection risk

The PCAOB's June 2024 amendments on technology-assisted analysis kicked in for fiscal years beginning on or after December 15, 2025. They give formal recognition to testing a whole population of transactions instead of pulling a sample. Common places it shows up:

Revenue and receivables
Inventory
Journal entries
Credit losses
Investments

They also settle how to classify a full-population procedure, which sets how much evidence it carries. A test of details examines individual items against source evidence. A substantive analytical procedure builds an expectation of the number and investigates the variances. For a significant risk, analytics alone won't clear the bar, so you need tests of details.

Test 100% of a population and sampling risk goes to zero. The PCAOB's sampling standard has always treated fully examined items as outside the sample. Detection risk doesn't go with it, though. It still turns on whether the procedure is the right one and whether you ran it well: point a full-population match at the wrong criteria and you've bought zero sampling risk on a test that answers the wrong question. The data has to hold up too. When the evidence is electronic, that means testing the relevant IT general controls and automated application controls, or you can't show the population you tested is the one that actually hit the general ledger.

One thing the amendments don't do: hand you a formula for resetting acceptable detection risk once sampling risk hits zero. That stays your judgment, and it now extends to the tooling that produced the result. A full-population procedure is only as sound as the logic behind it, and generative-AI tools carry limits of their own.

The inherent risk factors that make an assertion hard to audit

Every piece of audit risk comes down to a judgment call. Nobody picks it off a rating scale. Assess inherent and control risk separately, then ask the real question: what makes this particular assertion hard to audit?

Four things usually drive it:

Complexity buries errors in the mechanics: consolidation, multi-element revenue, or derivative valuation, where you have to do real work just to unwind the calculation.
Subjectivity leans on judgment, which is where estimates like credit loss allowances, impairment, and warranty reserves live.
Change undercuts last year's playbook: a new revenue stream, a new ERP rerouting how entries get booked, a policy adopted mid-year.
Management bias raises the temperature anywhere management has both a reason and the room to nudge a number: period-end accruals, one-off gains, or a reserve release that happens to hit the earnings target.

Some of that you just can't put a number on. There's no decimal for management bias, and pretending there is one is how a heat map ends up doing the team's thinking for it.

Estimates are where all of this shows up in the file. Subjective assumptions, measurement uncertainty, and bias can each move the number, and inspection findings keep showing what goes wrong when teams don't properly test estimates: problems across revenue, business combinations, credit losses, and impairment. Those misses almost always trace back to the assessment, not the testing. Rate the risk to fit last year's program instead of this year's facts, and you get exactly the deficiencies the inspectors write up.

Run risk-responsive engagements on Fieldguide

The risk model decides where your evidence has to go; getting it there is an execution problem. Fieldguide is an end-to-end AI-native platform purpose-built for audit and advisory firms. It covers the engagement from risk assessment through reporting, so a mid-engagement revision and the procedures it changes live in the same system as the workpapers they affect. Field Agents execute testing and documentation workflows and analyze uploaded evidence, while practitioners direct the engagement and own every judgment the model demands. Request a demo to walk through your own engagement workflow.