Embedded on paper
A 1,200-person construction consultancy merged two firms 18 months ago. Two risk processes still run in parallel: one uses a five-step process and a risk register per project; the other uses a 'risk log' reviewed at monthly commercial meetings. Twelve months ago the firm bought an enterprise GRC tool. It has 47 mandatory fields, and risk owners complete entries an average of 11 days after the meeting. A self-assessment against the firm's maturity model scored 4 out of 5 ('managed'). Yet a review of 20 projects found that 70% of risks had no response action recorded, a third of named risk owners had changed role and not been re-briefed, risk appears as the last 10 minutes of the monthly project meeting, and there is no review of whether risk management changes decisions. The tool vendor's renewal is due.
1. Distinguish between compliance with the risk process and embedding of risk management, using evidence from this setup.
Read the worked answer
Compliance is about whether the process is being followed. Embedded risk management is about whether it changes decisions and behaviour, is used because it helps, and survives changes in staff. The two are often confused because both can produce a populated register.
Evidence of compliance. The GRC tool is populated; risk appears on the monthly agenda; a maturity self-assessment has been completed and scored 4 out of 5. On paper, the process exists and is being operated.
Evidence against embedding. Two processes still run in parallel after 18 months, so there is no single approach that people recognise. 70% of risks have no response action, which means data is captured without decisions being made. A third of owners changed and were not re-briefed, so ownership is nominal and does not survive staff movement. Risk is the last 10 minutes of the meeting, which signals low priority and leaves no time for decisions. Entries are made 11 days after the meeting, so the tool serves retrospective reporting rather than live management. There is no measure of whether risk management changes decisions.
Conclusion. The firm has a well-populated process that is not embedded. The maturity self-score measures presence, not effectiveness, and should not be relied on.
2. Design a health check that would test whether risk management is effective rather than merely present. What would you examine, and how?
Read the worked answer
Document and data review. Read the approach and both legacy processes; sample 20 risks and trace each from identification through assessment, response, action, monitoring and closure. Check whether every 'high' risk has a named owner, a resourced response and a date.
Interviews. Ask owners and senior managers to describe their top risks, the response, and the appetite it is judged against. If they cannot, ownership is not real. Include people who have left or changed role to test handover.
Observation. Attend project and commercial meetings and observe when risk is discussed, whether it comes before or after decisions, whether options and costs are presented, and whether anything is decided.
Outcome evidence. Look for decisions that changed because of risk information: escalations, stopped work, changed suppliers, additional assurance, re-planned milestones. Absence of such evidence is a finding.
Maturity assessment with evidence criteria. Score each element (principles, approach, process, perspectives, roles, tooling) against defined criteria, and require the reviewer to cite evidence for each score rather than self-assessing. Distinguish 'present', 'used' and 'effective'.
Culture. Test whether bad news travels upward, whether people are blamed for raising risks, and whether the two legacy cultures are still competing.
Output. A prioritised improvement plan with owners and dates, and a re-check in six months. The central test is simple: would any decision have been different if risk management had not happened?
3. What should the firm do about the GRC tool?
Read the worked answer
Diagnose the tool's effect on behaviour. 47 mandatory fields and an 11-day entry lag mean the tool is shaping work badly: it rewards retrospective box-ticking and consumes time that could be spent on decisions. The tool is not the root cause, but it is reinforcing the problem.
Define the process first, then configure. Decide the minimum data needed to support decisions: risk description, cause, effect, objective affected, owner, response, action and date, rating with perspective, and escalation status. Reduce mandatory fields to that set and make meeting views simple.
Change when capture happens. Allow risks to be captured and updated in the meeting, or immediately after, rather than in a separate administrative task days later. Integrate with existing project workflow so it is not a parallel activity.
Use the renewal as a decision point. Set requirements - owner dashboards, action tracking, escalation, simple entry, support for both legacy processes until they are unified - and evaluate the vendor against them. Pilot any change on three to five projects before committing.
Do not let the tool define maturity. A populated tool is not evidence of embedded risk management. Measure success by use in decisions, action closure and owner engagement, not by field completeness. If the contract cannot be changed, use a light front-end and export to the tool rather than forcing the full form on users.