The register only wakes up before a meeting
Risks are refreshed in the fortnight before the committee meets, so the register records a point in time rather than the current position.
Enterprise Risk Management
One risk register the board, the business and internal audit all read from
Most risk registers are built for a meeting, not for the year. ERM in RiskMan GRC keeps one register live all year — each risk with an owner, a rating that follows a defined scale, a treatment plan with dates, and a clear line to the controls that mitigate it and the audits that test it. When the Risk Management Committee or the Board asks what has moved since last quarter, the answer comes off the register rather than out of a freshly built deck.
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.
Every function scores differently
Without a published likelihood and impact scale, a 'high' in operations and a 'high' in treasury do not mean the same thing, and the heat map cannot be read across the group.
Ownership is implied, not recorded
Mitigation sits with a department rather than a person, so nothing is ever overdue and nothing is chased.
Risk and assurance run on separate tracks
The audit plan and the control set are built independently of the register, so the areas rated highest are not necessarily the areas being tested.
With ERM
- One register, one scoring scale and one taxonomy across the group
- Inherent and residual ratings held separately, with the control effect visible in between
- A named owner, a treatment plan and a review date on every risk
- Appetite and tolerance stated, with breaches flagged rather than debated
- Audit planning and control testing scoped from the same ratings
- Committee reporting produced from live data instead of rebuilt each quarter
What ERM does
Maintain the enterprise risk register with owners, scoring, treatment plans and appetite thresholds. Heat maps and management reporting read from the same register the audit and control modules use.
Risk register and taxonomy
A structured register with a group taxonomy — strategic, operational, financial, compliance, technology and ESG — so risks are grouped consistently across entities and functions.
- Entity, function and process tagging
- Cause, event and consequence captured separately
- Group and subsidiary level registers
Scoring on a defined scale
Likelihood and impact scales are configured once and applied everywhere, with inherent, current and residual ratings held against each risk.
- Configurable 3x3, 4x4 or 5x5 matrices
- Financial, regulatory and reputational impact criteria
- Rating history retained for trend analysis
Appetite and tolerance
Record the appetite statement for each risk category and the tolerance threshold that triggers escalation, so an exception is identified by the system rather than argued in a meeting.
- Category-level appetite statements
- Tolerance thresholds with breach flags
- Escalation routing when a threshold is crossed
Treatment plans that are tracked
Each response — accept, mitigate, transfer or avoid — carries an owner, milestones and target dates, so overdue treatment is visible without a status call.
- Owner and due date on every action
- Milestone level progress
- Reminders before and after the due date
Key risk indicators
Attach KRIs to a risk with thresholds and a reporting frequency, so movement shows up as data between formal reviews.
- Threshold bands per indicator
- Period-wise capture with trend line
- Breach log for committee reporting
Linked to controls and audits
Map each risk to the controls that mitigate it and the audits that test it, so coverage gaps and over-testing are both visible.
- Risk to control mapping
- Risk to audit universe mapping
- Uncovered risk and untested control views
Heat maps and dashboards
Heat maps, top-risk views and movement charts render from the register itself, filtered by entity, category or owner.
- Inherent versus residual heat map
- Top risks by rating and by movement
- Filters by entity, category and owner
Review cycle and audit trail
Risk owners confirm or revise their risks on a set cycle, and every change is stamped with who changed what and when.
- Scheduled owner attestation
- Change log on rating and treatment
- Snapshot retained at each reporting date
ERM on screen
Screenshots taken from the live product.
The register at a glance
The dashboard opens on the position as it stands — total risks, how many are active, and how many are waiting on owner acknowledgement — with filters for department, category, status and owner so the same view narrows to one function without a separate report.
How a cycle runs
The steps in the order your team will actually work through them.
- 1
Identify
Capture risks from workshops, process reviews, audit findings, incidents and loss events into one register under the group taxonomy.
- 2
Assess
Score likelihood and impact on the published scale, record inherent and residual positions, and let the difference show what the controls are doing.
- 3
Respond
Decide the treatment, assign the owner, set milestones and dates, and record the residual position the response is expected to reach.
- 4
Monitor
Track KRIs, treatment progress and tolerance breaches through the period rather than at the end of it.
- 5
Report
Produce the committee view — heat map, top risks, movement and overdue treatment — directly from the register.
What you have at the end
The records the module produces, and the regulations and frameworks they help you meet.
Reports and records
- Enterprise and entity-wise risk register extract
- Inherent versus residual heat map
- Top risk dashboard for the Risk Management Committee
- Risk movement and trend report for the period
- Treatment plan status and overdue action report
- KRI dashboard with threshold breach log
- Risk owner attestation record
- Risk to control and risk to audit coverage map
Built around
- COSO ERM (2017)
- Register, appetite and reporting structured along the framework's components.
- ISO 31000:2018
- Identify, assess, treat, monitor and report lifecycle.
- Companies Act 2013 — Sec 134(3)(n)
- Supports the risk management statement in the Board's Report.
- Companies Act 2013 — Sec 177(4)
- Supports Audit Committee evaluation of risk management systems.
- SEBI LODR — Reg 21
- Reporting pack for the Risk Management Committee of listed entities.
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.
- Chief Risk Officer / Risk head
- Owns the taxonomy, the scales and the appetite, and runs the group review cycle.
- CFO and business heads
- Own the risks in their area and the treatment plans against them.
- Internal audit
- Uses the ratings to build a risk-based plan, and feeds findings back as risks.
- Risk Management Committee / Board
- Reads the heat map, top risks and movement, and sees breaches against appetite.
Questions we usually get
Don't see your question here? Write to us and we'll answer it for your setup.
Can we keep our existing risk scales and categories?
Yes. The matrix size, the likelihood and impact definitions and the risk taxonomy are configured to your framework. The point of the module is to apply your scale consistently, not to impose a new one.
How does this connect to internal audit planning?
Risks carry a link to the auditable entities in the Risk Based Internal Audit module, so the annual plan can be built off current ratings and coverage gaps against high-rated risks are visible before the plan goes to the Audit Committee.
Can subsidiaries run their own registers?
Yes. Each entity can maintain its own register while rolling up to a group view, with the same taxonomy and scales applied so the consolidated heat map is comparable.
Is there an audit trail on changes to a risk?
Every change to rating, ownership, treatment or status is recorded with the user and timestamp, and a snapshot is retained at each reporting date so a past committee pack can be reconciled to the register.
See ERM 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.
Other RiskMan GRC modules
View the full product- Risk Based Internal AuditPlan by risk, approve the plan, assign it process-wise and execute it.
- Control TestingRun a testing project end to end — RCM, IDR, testing, approval, management response and report.
- Action Taken ReportTrack every observation through to closure, with owners and due dates.
- Policy and SOPOne library for policies and SOPs, with versions and approvals tracked.
- Global SOXFor groups testing the same SOX controls across many entities. One control library, one approved scope, and projects that end in a signed-off report.