CASE STUDY · ENTERPRISE RISK MANAGEMENT FRAMEWORK
Group-wide risk management, from food safety to cyber
A UK chilled food manufacturer, multi-site, set out to mature enterprise risk management across the group. The order mattered: agree the governance, define the process, identify and assess the risks, and only then select the tooling to host it all. ICA Consultancy designed the framework, built the risk and control library, and taught the team to operate it.
8
risk domains in the risk universe
2
tiers of risk
7
defined roles, from Executive to action owner
4
steps in the cycle
Governance first, then the tool
Tooling is the easy part of enterprise risk management to specify and the hardest to specify well.
A platform hosts a method, it does not supply one. Choose it before the method exists and you are configuring someone else's assumptions about your risk language, your scoring, your ownership model and your escalation routes, then adapting your organisation to fit.
This organisation sequenced it deliberately. Define how risk is governed and how the process runs. Populate the risk universe and assess real risks against it. Establish what the data actually looks like in practice. Then evaluate tooling against a known specification, with your own risks, your own taxonomy and your own reporting requirements as the test.
The result is a platform decision made from evidence rather than a demo, and a framework that would survive changing the platform later.
What was designed
ERM Framework
How risks are identified, assessed, controlled and monitored across every site, roles and responsibilities, consistent risk language, impact and likelihood matrices so scores are comparable between a food safety risk and a cyber risk, and defined reporting and escalation.
Two-Tier Risk Structure
Tier 1 strategic risks monitored at the top of the organisation. Tier 2 sub-risk scenarios beneath them, which is where controls are mapped. The structure deliberately allows a third tier later without redesigning anything, the framework matures with the business rather than being replaced by it.
Risk & Control Library
Risks recorded, inherent scores assessed, controls mapped, control adequacy and effectiveness rated, residual risk calculated, and corrective action plans linked to the specific control weakness that caused them. Plus the dashboard that turns all of it into something a committee can read.
RACI
Executive Committee, Risk Committee, ERM Support Function, Risk Owners, Control Owners, Assurance Providers, Action Owners, each with what they own, what they produce and what they escalate. Most risk frameworks fail here rather than on methodology.
Then we taught them to run it
The engagement was built around knowledge transfer from the start. A training workshop on the framework and the library, then a facilitated risk assessment workshop on one Tier 1 risk, Cyber and IT, with the client's stakeholders in the room doing the assessment rather than watching one happen.
Those stakeholders then had the material, the method and the experience to repeat it for the remaining Tier 1 risks themselves. Ongoing support was offered as an option, not built into the design. The client's own Group Financial Controller put the intent better than we would have: teach me to fish, rather than consistently feeding me the best mackerels.
That is the measure of whether an ERM design has worked. Not whether the consultant is still there, whether they don't need to be.
How an ICA Consultancy ERM design engagement runs
Five stages, from scoping conversation to delivered framework.
What an ERM design engagement is, and what it is not
Designing the framework does not manage the risk. This engagement produces the method, the structure and the capability to operate it; the organisation identifies, owns and treats its own risks, because risk ownership cannot be outsourced to the people who designed the register. Nor does it replace assurance, independent testing of whether controls actually work sits outside the process, deliberately. It is also not a tooling selection exercise, though it is what makes one possible: the framework defines the requirements a platform then has to meet.