A risk assessment is the moment an engagement either gets scoped well or drifts for the next three months. Get it right and everything downstream — the test steps, the evidence requests, the report — points at what actually matters. Get it wrong and you spend the fieldwork testing controls over risks nobody cares about while the real exposure goes untested.
This guide is about the engagement-level risk assessment: the one you run when you already have a single process or entity in front of you and need to scope the fieldwork. That is a different exercise from the annual, audit-universe-level risk assessment that produces the whole audit plan. For the entity-level version — ranking every auditable entity to build the risk-based plan under IIA Standard 9.4 — see Internal Audit Risk Assessment Methodology. This article picks up where that one leaves off: you have decided to audit a process, and now you need to scope it defensibly. It is practical and copy-and-use — the framework, a template you can paste into a workpaper, and a worked example.
What an Engagement-Level Risk Assessment Is
An engagement-level risk assessment is the structured process of deciding what to test, and why, within a single engagement. You take the in-scope process, articulate its objectives, identify the risks that threaten those objectives, rate how much exposure each risk carries, account for the controls already in place, and then prioritize the residual exposure that deserves your limited testing hours.
The output is not a list of risks. The output is a defensible scope: a documented line from each objective, to each risk, to the procedures that will test whether the controls work. IIA Standard 2010.A1 requires the engagement work program to be based on a documented assessment of the risks relevant to the activity under review — this is how you produce it.
The Step-by-Step Framework
Here is the sequence. Each step feeds the next, and each step gets documented.
Step 1 — State the process and its objectives
Before you can name a risk, you have to name what the process is trying to achieve. "Procure-to-pay" is not an objective. "Only authorized purchase orders are approved and paid, at agreed prices, to legitimate vendors" is. Write two to five objectives in plain language.
Step 2 — Identify what could go wrong
For each objective, ask: what would have to fail for this objective not to be met? Those failures are your risks. Phrase them as conditions, not controls. "Duplicate payments are issued" is a risk. "No three-way match" is a missing control — put that in Step 4.
Step 3 — Rate inherent risk
Rate each risk on two axes — likelihood and impact — before considering controls. A simple 1-to-5 scale on each, multiplied, gives an inherent risk score from 1 to 25. Keep the scale definitions written down so a reviewer can see why you scored a 4 and not a 2.
Step 4 — Map existing controls
For each risk, note the controls that are supposed to mitigate it. This is where the risk-control linkage forms. If a high-inherent-risk item has no mapped control, that is itself a finding waiting to happen — flag it.
Step 5 — Estimate residual risk
Residual risk is inherent risk adjusted for the strength and reliability of the mapped controls. A high-inherent risk with a strong, tested, automated control may drop to low residual. A moderate-inherent risk with a manual, undocumented control may stay high. This is judgment, and it is the judgment the AI cannot make for you.
Step 6 — Prioritize for testing
Rank by residual risk. Your test steps concentrate on the top of the list. Document why lower-residual risks are receiving less coverage — those "not tested and here is why" notes are exactly what a quality reviewer looks for.
The Free Risk-Scoring Template (Copy This)
Paste this straight into your workpaper. It is the whole scoring model in one table.
| # | Objective | Risk (what could go wrong) | Likelihood (1-5) | Impact (1-5) | Inherent (L x I) | Existing control(s) | Control strength (H/M/L) | Residual (H/M/L) | Test? |
|---|---|---|---|---|---|---|---|---|---|
| 1 | |||||||||
| 2 | |||||||||
| 3 |
Scoring key for likelihood and impact:
| Score | Likelihood | Impact |
|---|---|---|
| 1 | Rare | Negligible |
| 2 | Unlikely | Minor |
| 3 | Possible | Moderate |
| 4 | Likely | Major |
| 5 | Almost certain | Severe / material |
Residual rule of thumb: start from the inherent band (Low 1-6, Medium 8-12, High 15-25), then move it down one band for a strong control, hold it for a moderate control, and hold or raise it for a weak or missing control.
A Worked Example: Procure-to-Pay
Here is one row filled in so the model is concrete.
| # | Objective | Risk | L | I | Inherent | Control | Strength | Residual | Test? |
|---|---|---|---|---|---|---|---|---|---|
| 1 | Only authorized POs are paid | Duplicate or fraudulent payments issued | 3 | 5 | 15 (High) | System three-way match; dual approval over threshold | Medium | High | Yes |
| 2 | Vendor master data is legitimate | New vendors added without vetting | 3 | 4 | 12 (Medium) | Segregation between vendor setup and payment | Medium | Medium | Yes |
| 3 | Prices match agreed terms | Overpayment vs. contract price | 2 | 3 | 6 (Low) | Buyer review of price variances | Low | Medium | Maybe |
Row 1 is where your fieldwork hours go. Row 3 stays light — but you documented why, which is the point.
Where AI Fits (and Where It Must Not)
The blank-page portion of this — drafting the objectives, generating the candidate risks, proposing initial inherent ratings from the process context — is exactly what AI does well. It reads your scope inputs and produces a substantive first draft instead of a cursor blinking on an empty template.
What AI must not do: make the residual-risk call, decide what is acceptable, or finalize the scope. Those are professional judgment, and under the IIA's 2024 Standards they stay with the auditor. The right pattern is AI drafts, the auditor reviews and adjusts, and the workpaper shows both. We cover the compliance framing in depth in how to use AI in audit without failing your next QAR.
How Audvera Supports This
Everything above runs in a spreadsheet. The friction shows up afterward: the objectives, risks, inherent ratings, control mappings, and residual calls end up spread across tabs, and by the time you are in fieldwork the reviewer has to reconstruct how the scope was decided. Audvera keeps the objective-to-risk-to-procedure chain linked, so an engagement's risk assessment stays connected to the test steps, evidence, and preparer/reviewer signoff instead of drifting apart. AI drafts the first-pass objectives and candidate risks from your scope inputs; the residual-risk and testing decisions stay with you, and the workpaper shows who ran the assistant and who reviewed it.
If you want to see it against your own scope, start with a free risk assessment — describe the process and Audvera drafts an initial objective-risk-procedure skeleton you can review and tailor.