How many auditable entities should we have?

Enough that each one has an owner and a scope you could write on one page, and few enough that you can score all of them once a year. For most mid-sized organisations that lands between 30 and 80. Hundreds usually means you have listed processes; a handful means you have listed departments.

Should the risk score decide the plan by itself?

No. The score orders the queue. The plan is the score plus judgement: regulatory dates, a new system going live, a change of management, and the coverage you owe the audit committee over three years.

How often should we redo the risk assessment?

Once a year in full, with a short review at the half-year. The half-year review is where you catch the entity whose risk changed because something happened, which is the whole point of doing this rather than repeating last year's plan.

What if management disagrees with a score?

Record the disagreement, keep both views visible, and let the audit committee see them. A risk assessment nobody argued with is usually one nobody read.

How to build a risk-based annual audit plan, from questionnaire to heatmap

A risk-based annual audit plan answers one question: given what we can cover this year, where should we look first? It starts from a list of things that can be audited, scores each one for risk, and turns the ranking into a dated schedule that the audit committee approves. The work is not the arithmetic. It is agreeing the list, agreeing what risk means here, and being able to show how the answer was reached a year later when someone asks.

Here is the sequence, and where each step usually goes wrong.

1. Agree the audit universe

The audit universe is the list of auditable entities: the processes, systems, locations or business units you could audit. Each needs a name, an owner and a scope you could summarise in a paragraph.

Where it goes wrong: listing the org chart instead of the work. "Finance" is not an auditable entity; "revenue recognition", "procurement to pay" and "payroll" are. The test is whether you could write a scope and name the person who would answer for it.

2. Decide what risk means, once

Pick the factors you will score every entity against, and write down what each one means. A workable set is small: financial exposure, regulatory exposure, complexity, change in the last year, past audit findings, and management's own view.

Give each factor a weight, and write down why. The weights are a policy decision, not a calculation, and they are what you will be asked about.

Where it goes wrong: inventing a new factor for one entity because it feels riskier. The moment the model bends for a single case, the ranking stops being comparable.

3. Collect the answers with a questionnaire

Score each entity by asking the same questions about all of them, and ask the entity's owner as well as the audit team. Two sources matter: management's view of their own risk, and yours. Where they differ, you have found something worth a conversation before fieldwork starts.

Where it goes wrong: the audit team scores everything alone, in a room, in a week. The scores are defensible but no one else feels any ownership of them, so the plan lands as a surprise.

4. Score, weight and rank

Combine the answers into a score per entity. Keep the arithmetic boring and visible: a weighted average that anyone can reproduce beats a clever model nobody can explain to the audit committee.

A heatmap is the output people actually read: entities placed by likelihood and impact, so the top-right corner is the year's work. Its job is to make the ranking arguable in a meeting, not to look impressive.

Where it goes wrong: precision theatre. A score of 7.34 implies an accuracy that a questionnaire cannot give you. Bands, or a simple 1 to 5, survive scrutiny better.

5. Turn the ranking into a plan

Now add the things a score cannot see:

Cycle coverage. Some entities must be seen every year or every three years, whatever they score, because the audit committee or a regulator expects it.
Timing. A system going live in Q2 is best audited in Q3, not in January.
Capacity. Count the audit days you actually have, after leave, training, follow-up work and the investigations that always arrive. Plan to about 80% of that number.
Follow-up. Re-checking last year's action plans is work. Put it in the plan or it happens in the evenings.

The result is a schedule: which audits, in which quarter, with how many days and who leads.

6. Get it approved, and keep the trail

The audit committee approves the plan, and that approval is only as good as the trail behind it: the entity list, the questionnaire answers, the weights, the scores, and the judgement calls you made on top of them. When a plan is questioned in month nine, this is what answers it.

Where it goes wrong: the trail lives in one spreadsheet on one laptop, with last year's version beside it, and nobody can say which numbers produced the approved plan.

Doing it in AuditEase Pro

The steps above are the product's planning flow: the audit universe holds the entities and their owners, questionnaires collect the scoring answers from both the audit team and the business, risk scoring applies your weights, and the heatmap shows the ranking. The annual plan then turns the ranking into scheduled audits with teams and dates, and the trail from answer to score to plan stays in one place.

The weights and the questionnaires are yours: they are configured to your methodology when your deployment is built, because a risk model that came with the software is a model you will spend a year explaining.

You can walk the whole flow in the live demo, which holds a fictional organisation with its entities, questionnaires and a heatmap already in place.