Risk Based Internal Audit

A plan built on risk, approved on record, and assigned process by process for execution

Internal audit is judged twice — once on whether the plan covered what mattered, and again on whether the file supports the report. This module holds both ends. The plan is built from the audit universe and risk factor scoring, with assurance mapping available where you want to see what other providers already cover, and it goes through formal approval. Once approved, it is assigned process-wise, and from that point the steps are the same ones a control testing run follows — project, RCM upload, IDR release, testing, approval, management response, approval and report — so the plan and the evidence behind it stay in one line.

Request a demo Talk to a specialist

Where it usually goes wrong

Most teams know how to do this work. The trouble is that it lives in workbooks, mail threads and shared folders, and keeping them in sync becomes a job of its own.

This year's plan is last year's plan

Coverage is carried forward by habit, and there is no record showing why one area was audited and another was not.

The approved plan and the executed plan differ

Assignments change through the year without a record, so what the committee approved and what was actually done are reconciled from memory.

Execution runs on a different system to planning

The plan sits in one place and the testing file in another, so coverage status has to be collated rather than read.

Internal audit repeats work others have already done

Without a view of what management testing, external audit or a regulator already covers, effort goes into areas that are already assured.

With RBIA

An audit universe scored on defined risk factors
Optional assurance mapping showing what other providers already cover
A plan that is formally approved, with the approval on record
Process-wise assignment, so every line of the plan has an owner
Execution on the same steps every testing run follows, with one evidence trail
Plan versus actual coverage readable at any point in the year

What RBIA does

Build the audit universe, score it on risk factors, map existing assurance where required, and take the plan through approval. Once approved, the plan is assigned process-wise, and from there each process follows the same steps as a control testing run — project, RCM, IDR, testing, approval, management response, approval and report.

Audit universe

A maintained library of auditable entities — processes, locations, subsidiaries, systems and projects — with the attributes used to rank them.

Process, entity, location and system dimensions
Last audited date and prior rating retained
Reviewed and updated each planning cycle

Risk factors and scoring

Score each auditable entity on weighted risk factors, drawing current ratings from the ERM register, so the ranking reflects the same risk view the board sees.

Configurable risk factors and weights
Current residual ratings drawn from ERM
Ranked universe with the scoring rationale retained

Assurance mapping (optional)

Where you want it, map significant risks to the assurance they already receive — management testing, control testing, external and statutory audit, regulatory inspection — so the plan is set on where assurance is missing rather than on where it is easiest to repeat.

Risk mapped across the three lines and external providers
Gaps, duplication and over-assurance made visible
Optional step — used where the coverage picture matters

Plan preparation

Turn the ranked universe into a plan with periods, teams and effort, drawn from the scoring and the assurance view rather than from last year's list.

Annual, rolling and ad-hoc engagements
Resource and man-day allocation
Scoring rationale carried with the plan

Plan approval

The plan goes through formal approval before execution, and the approved version is the baseline against which the year is measured.

Approval recorded with authority and date
Approved plan locked as the baseline
Subsequent changes tracked against it

Process-wise assignment

The approved plan is broken down process by process and assigned to teams with periods and timelines, so every line has a named owner and a date.

Assignment by process with team and period
Reviewer and approver named at assignment
Reassignment tracked against the approved plan

Execution, step by step

From assignment onward the steps are the same ones a control testing run follows — a project is created, the RCM is uploaded, the IDR is released, testing is done and approved, the management response is filled and approved, and the report is generated.

A project per assigned process
IDR, testing and evidence held in the project
Management response approved before the report

Coverage and status analytics

Track plan versus actual coverage, the status of each assigned process and observations arising, across the year rather than at the end of it.

Plan versus actual by period and process
Status of every assigned process in one view
Observation counts by rating and process

RBIA on screen

Screenshots taken from the live product.

The plan, once it is approved

The plan overview reads the way the plan is built — audit universe, risk framework, scoring, annual plan and assignments across the top, and underneath it the scored universe by band, what the year commits to, and the quarter each auditable area falls in. The approval is stamped on the record with who submitted it and who approved it.

How a cycle runs

The steps in the order your team will actually work through them.

1
Build the universe
Define and maintain auditable entities, each with its owner, its prior coverage and the risks it carries.
2
Score on risk factors
Apply the weighted risk factors and the current ratings from the register, and rank the universe on the result.
3
Map assurance (optional)
Where the coverage picture matters, set the ranked universe against the assurance each risk already receives from management, external audit and regulators before committing audit effort.
4
Prepare the plan
Convert the ranking into a periodised plan with teams and effort, carrying the scoring rationale with it.
5
Approve the plan
The plan is formally approved and becomes the baseline for the year, with the approval recorded.
6
Assign process-wise
Break the approved plan down by process and assign each one to a team with its period and timeline.
7
Execute
From here the steps are the same as a control testing run — create the project, upload the RCM, release the IDR, test, approve the testing, fill the management response, approve it and generate the report.
8
Report and follow up
Observations and agreed actions from the executed processes go to the Action Taken Report module and are closed against evidence.

What you have at the end

The records the module produces, and the regulations and frameworks they help you meet.

Reports and records

Audit universe with scoring rationale
Risk factor scoring sheet and ranked universe
Assurance map by risk and assurance provider, where used
Risk-based annual internal audit plan
Approved plan with approval authority and date
Process-wise assignment schedule with teams and periods
Executed testing file and report for each assigned process
Plan versus actual coverage dashboard and committee pack

Built around

Companies Act 2013 — Sec 138 and Rule 13: Supports the internal audit requirement and the scope set by the Board or Audit Committee.
Companies Act 2013 — Sec 177: Reporting structure for Audit Committee review of internal audit.
SEBI LODR — Reg 18: Committee pack covering internal audit findings and follow-up for listed entities.
ICAI Standards on Internal Audit: Planning, documentation, evidence, supervision and reporting structured around the SIA framework.
IIA International Professional Practices Framework: Risk-based planning, engagement conduct and quality review practices.

These references describe the context the module is designed to support. They are not a statement of certification, and do not replace professional judgement on your reporting obligations.

Who works in it

Everyone works on the same record. Each person sees the part they are responsible for.

Head of Internal Audit: Owns the universe, the scoring, the plan and the Audit Committee relationship.
Approving authority: Approves the plan before execution begins, and approves changes to it during the year.
Engagement teams: Take the processes assigned to them and execute each through the control testing flow.
Process owners and auditees: Respond to the IDR, fill the management response and commit to actions with dates.

Questions we usually get

Don't see your question here? Write to us and we'll answer it for your setup.

How does the plan get built?

From the audit universe, scored on your weighted risk factors with current ratings pulled from the risk register. Assurance mapping can be added where you want to see what management testing, external audit or a regulator already covers before internal audit commits effort — it is an optional step, not a required one.

What happens after the plan is approved?

The approved plan is assigned process-wise, with a team, a period and a timeline against each process. From there the steps are the same ones a control testing run follows — project creation, RCM upload, IDR release, testing, approval, management response, approval and report.

Is execution separate from planning?

No. The assignment links the plan line to the project that executes it, so coverage status, testing status and the report all read back to the approved plan instead of being collated separately.

Can changes to the approved plan be made during the year?

Yes, and they are tracked against the approved baseline rather than replacing it, so the committee can see what was approved, what changed and why.

Where do observations go once a process is executed?

Observations and the actions management commits to in the response step flow into the Action Taken Report module, where each is tracked to an evidence-backed closure.

See RBIA on your own data

Book an hour with our team. We will run the module on your own process and control matrix, so you can see how a full cycle would look for you.

Book a walkthrough Ask a question

Other RiskMan GRC modules

View the full product