Why a cycle, not a document
Most regulated firms in Thailand can show a risk management policy, a risk register and a committee that meets. What supervisors and auditors look for is harder to show: that the register is alive, that the scores mean the same thing every quarter, that a loss that happened last month changed something, and that a decision taken at the committee can be traced to an action with an owner. That is what a framework does when it runs as a cycle rather than as a set of files.
COSO's 2017 framework describes enterprise risk management in five components, from governance and strategy through performance, review and reporting. In practice the day-to-day work sits in six stages that repeat, and the test of a framework is whether each stage writes to the same record the next one reads.
The six stages
- Identify. A risk is entered in the entity's risk register with its category, owner, cause and treatment. Loss events are recorded as they happen. The critical activities the business cannot afford to lose are listed in the business impact analysis (BIA).
- Assess. Likelihood and impact are scored on one criteria set that applies to the whole group; inherent and residual risk, the tier and the rating band follow from the scores. A loss event's materiality tier follows from the group's thresholds. Risks above appetite are flagged.
- Respond. Controls and treatment are recorded against each risk, and controls are tested. A failed test, or a finding that needs follow-up, becomes an action item with an owner and a due date.
- Monitor. Key risk indicators are observed against Green, Amber and Red bands. Loss events are validated and their valuation kept current. A hazard alert becomes a continuity level that staff can see.
- Recover. When a disruption happens, the continuity side takes over: a BCP level is set, staff check in, and the call tree reaches the critical activities first, in the order and recovery time the BIA set.
- Report and review. Each entity's RCSA filing is reviewed and approved; each entity files its monthly loss report. Dashboards and the group roll-up are built from what was approved and reported up. The management review reads them and its decisions become action items, which return to the register.
Figure 9The risk life cycle: six stages on one registerEach stage writes to the registers the next stage reads. Decisions from the review become action items and return to the register, where the next cycle starts from what was approved. The recover stage is the continuity side of the same core.
What makes it a cycle rather than a checklist
A checklist is six things done once. A cycle is six things that feed each other, so that evidence from one stage changes the next:
- A loss event is tied to a risk in the register, so the heat map reflects what actually happened, not only what was estimated.
- Each indicator is defined against a risk, and a Red observation creates an action item rather than a note in a meeting.
- The BIA and the risk register point at each other: a critical activity shows the risks that threaten it with their residual scores, and a risk shows whether it protects a critical activity.
- Closing a continuity incident creates a draft loss event, and every change of continuity level is recorded as an indicator observation, so the continuity side feeds the risk side without anyone re-keying.
- Decisions become action items, with an owner and a due date, in the same action register that control tests, breaches and single points of failure feed.
Where it usually breaks
- Each stage lives in a different file. The register is one workbook, the loss log another, the indicators a third, the BIA a fourth. Nothing links, so the committee pack is assembled by hand every quarter and the links are whatever the person assembling it remembers.
- Scores are typed, so scores are negotiated. When a residual rating can be entered directly, it tends to drift towards what the owner can live with. The scale then means something different in each business unit.
- A quiet month looks like a clean month. Without a formal nil return, a month with no loss report is indistinguishable from a month nobody filed.
- The continuity plan sits apart from the risk framework. The BIA is written for the auditor, and the call tree is written from the organisation chart, so the order in which teams are called has nothing to do with what the BIA says matters most.
In Risk Core
Risk Core — powered by Qirin X · ComplyWise. Its enterprise risk module, ERM Core, runs the six stages above as connected registers and workflows: one risk register, loss event register, KRI library and BIA per entity, scored on the group's one criteria set, with one action register and one audit log shared with the continuity module, BCP Core.
Two product rules carry most of the weight. Computed, never typed: scores, tiers, rating bands and statuses are derived by the system from the inputs, and there is no field to enter them. Who-filed is stamped: every record and every step carries its author and time, and history is append-only. The rest of this series takes one stage at a time — RCSA, loss events, KRIs, the BIA and the continuity link, and group governance — and shows what each rule looks like in use.
Platform summary and the ComplyWise services around it: Risk Core. Product documentation: ERM Core overview and Standards mapping on Risk Core Docs.
The series
Six articles, one stage at a time. Each one explains the framework first and ends with how Risk Core implements it.
- 1
Enterprise risk management in practice: the six-stage risk life cycle
- 2
RCSA in practice: a risk score nobody can type
- 3
Loss events in practice: the tier is computed, the month is always filed
- 4
Key risk indicators in practice: three bands, versioned thresholds, every Red is an action
- 5
From the business impact analysis to the continuity plan: how a recovery time becomes a call-tree order
- 6
Group risk governance in practice: each company runs its own, the parent reads up
Frequently asked questions
- What are the stages of the enterprise risk management cycle?
- In day-to-day practice: identify the risk, assess it on a common scale, respond with controls and treatment, monitor it through indicators and loss events, recover when a disruption happens, and report and review so that decisions return to the register. COSO ERM (2017) frames the same work in five components, from governance and strategy to review and reporting.
- What is the difference between inherent and residual risk?
- Inherent risk is the score before controls, from likelihood and impact. Residual risk is the score after the effectiveness of the controls is applied. Residual risk can never be higher than inherent risk.
- Why should risk scores be computed rather than entered?
- A rating that can be typed can be negotiated. When the score, tier and band are derived from the chosen likelihood, impact and control effectiveness on one criteria set, every entity in a group is on the same scale and the figures consolidate.
- How does business continuity fit into enterprise risk management?
- Through the business impact analysis. The BIA records which activities are critical, how fast each must recover and the minimum staffing, and the continuity plan is built from it. ISO 22301 places the BIA (clause 8.2.2) and the risk assessment (clause 8.2.3) side by side for that reason.
Sources
- Risk Core Docs — ERM Core overview: the risk life cycle and how RCSA, Loss Event, KRI and BIA feed each other
- Risk Core Docs — Product rules: the seven rules Risk Core enforces in the database
- Risk Core Docs — Standards mapping: COSO ERM (2017), ISO 22301:2019 and the Basel event types
- COSO — Enterprise Risk Management: Integrating with Strategy and Performance (2017), guidance page
- ISO 22301:2019 — Security and resilience — Business continuity management systems — Requirements
Accessed and last reviewed . Each figure and table cell is traced to a source above.