The risk management process is only as good as step one

The risk management process runs in five key steps, and most guides agree on that much: identify, analyse, evaluate, treat, monitor. Run it as an ongoing process, not a project with an end date. Those five steps rarely change between industries or company sizes, and almost nothing goes wrong inside them.

An effective risk management process is defined by that input, not by which five words label the boxes in the diagram. A compliance and risk management platform like Copla can hold that record once it exists. It cannot manufacture a good one out of a workshop and good intentions. What follows covers all five steps in detail, then the four places the entire risk management process still breaks.

The risk management process in five steps

The risk management process breaks down into five steps, run in order and then repeated:

1. Identify the risks that could affect the business, drawn from what it actually runs on, not from memory.
2. Analyse each one: cause, exposure, and which controls already sit against it.
3. Evaluate and rank risks by likelihood and impact, on a consistent scale.
4. Treat each risk: mitigate it, transfer it, avoid it, or accept it, with a named owner.
5. Monitor and review what changed, on a cadence that matches how fast the business actually changes.

This is a cycle, not a project with a finish line. A programme that runs it once a year and calls it done is managing risks in name only.

Why some guides say four steps and others say seven

The risk management process shows up with a different step count everywhere you look: four steps, five, six, sometimes seven. None of the guides explain why. The disagreement is cosmetic: everyone is splitting the same work into different-sized chunks.

None of this changes quality. A four-step version and a seven-step version can describe the same competent process, or the same broken one. Step count is not where a DORA ICT risk management framework earns its keep either: that document governs who owns the process and how often it repeats, not how many boxes sit in the diagram. The question worth asking is not how many steps a guide lists, or which one it happens to call step one. It is where that first step actually gets its inputs.

When the guide is really project risk management

A good share of what ranks for this topic is not written for a compliance or risk officer at all. It is project risk management, sometimes labelled the project risk management process: guidance for spotting the project risks that could derail a specific initiative, run by a project manager with a business case, a budget, and an end date, before the planning process even finishes. Project risk management and an ICT risk register both exist in the same business world. They are answering different questions for different people, and only one of them has a supervisor reading over its shoulder.

That distinction matters more than most guides admit. A risk register for a regulated financial entity has no end date, and project success was never the point. Reading advice written for project management and applying it to an operational or ICT risk register produces exactly the mismatch this article is about: steps that look right, and inputs built for a different question entirely.

The risk identification process is the first step in the risk management process, and it is supposed to produce one thing: a list of what could actually go wrong, specific enough that someone could act on any line of it without asking what it means. Most organisations get a list of identified risks. Few get one that clears that bar.

That list spans risk categories, and the category matters less than most guides imply:

Each one threatens the organisation’s financial stability or its standing with a regulator in a different way.

The standard method is a workshop: six people in a room, a whiteboard, an hour blocked out before lunch. Someone asks what could go wrong, and the room answers with whatever it remembers. None of that is wrong, exactly, but none of it is identification either. It is recall, and recall only surfaces what the people in the room have personally lived through:

• What the room remembers: last year’s outage, the vendor that missed a deadline, security breaches at a competitor, the human error that nearly caused an incident two Christmases ago.
• What the room rarely reaches: technology failures nobody at the company has experienced yet, natural disasters that hit someone else’s data centre, a data breach that took down a vendor two sectors over.

External risks and other external factors, the kind sitting outside the room’s own direct experience, are exactly what recall is worst at catching. A business with forty critical dependencies and six attendees will get, at best, six people’s worth of risk, filtered through whoever spoke first and loudest.

The fix is a different starting point, not a better workshop. Identification gets reliable when it starts from an inventory of what the business actually runs on: systems, vendors, business processes, and the dependencies between them. Paired with a business impact analysis that says which of those are critical and what breaks when each one fails, identification stops listing potential risks from memory and starts deriving them.

Unexpected events still happen either way. The difference is whether the register already accounted for the dependency they hit.

There is a simple tell for which version you are looking at. If a register would read identically at a competitor three times the size, in a different city, run by different people, listing the same similar risks in the same order, it was not derived from this business. It was recalled from general experience and typed up under this company’s letterhead. Some guides frame a sharp risk register as a source of competitive advantage. For a regulated entity the more immediate reward is smaller and more concrete: a register that survives a supervisor’s second question.

Risk analysis has one job: turn a one-line risk into something a person who was not in the room can actually reason about. That is the honest test: hand the register to someone new and see whether the logic survives without you standing there to explain it.

For each risk, analysis has to establish four things:

• What causes it, the specific mechanism, not a generic category.
• What it actually threatens, the outcome or asset at stake.
• Which business processes it touches, not just the vendor or system in isolation.
• What controls already exist against it, and whether they work in practice rather than only on paper.

Historical data helps answer the first of these where it exists, rather than guessing at a cause from scratch.

A vendor outage is not one risk event. It is a specific vendor, supporting a specific business process, with a specific control already in place, a failover, a contract clause, or nothing at all, and a specific reason the risk persists despite that control. Analysis is also where internal causes get separated from external factors, because the two call for different treatment later.

The shortcut most registers take is skipping straight from a one-line identification to a number, without stopping to analyse risks properly. It looks efficient. It produces a score with nothing underneath it: a five out of five with no cause, no affected process, and no account of the control supposedly already handling it. That kind of entry survives a first read and fails the first follow-up question, which is exactly the moment an auditor or a supervisor tends to ask it. Good analysis is what turns risk-related information into something decision making can actually use, rather than a number nobody can trace back to a cause.

How does one risk compare to another? Evaluation exists to answer exactly that, for every risk on the list at once. In practice this is qualitative risk assessment: likelihood multiplied by impact, on a consistent scale, applied the same way to every entry, so risks are ranked against each other and against a threshold that reflects the organisation’s risk appetite and the organisation’s objectives, not one borrowed from a template.

Two things keep that scoring honest rather than theatrical:

• Consistency beats sophistication. A simple five-point scale applied identically every time produces a more useful ranking than an elaborate model applied inconsistently, depending on who is scoring and what mood the room is in that week.
• Criticality has to already exist. Evaluation only works if it was established back in step one. Skip that, and everything scores high, because every risk looks serious once nothing has been ranked against what the business actually depends on.

It has just recorded a lot of numbers, and not all risks on that list actually carry the same risk exposure.

Some organisations attach a financial figure to each risk, an estimated cost if it materialises, so leadership can weigh it in terms it already uses for every other decision. That is a reasonable addition to a risk assessment matrix, not a replacement for one, and a different exercise entirely from a formal quantification model. A single estimated number next to a likelihood-and-impact score supports decision making at board level. It is a communication aid, not a substitute for the scoring underneath it. The point of scoring at all is to prioritise risks honestly enough that the organisation can allocate resources to the handful that actually deserve them.

Every risk gets one risk response strategy: organisations mitigate risks, transfer them, avoid them, or accept them. Risk treatment is the umbrella term for choosing between the four and making the choice stick.

• Risk mitigation reduces the likelihood or the impact, through a control, a redundancy, or a process change.
• Risk transfer shifts the financial consequence elsewhere, most commonly through insurance, or a liability clause in a vendor contract.
• Risk avoidance removes the activity that creates the risk entirely: the product does not launch, the vendor does not get used.
• Risk acceptance is a decision to carry the risk as it stands, made deliberately rather than by default.

Managing risks well is mostly a matter of choosing honestly between those four, not defaulting to the same one regardless of what the risk actually needs.

Acceptance is a real answer, and often the correct one. Not every risk justifies the cost of mitigating it. What makes risk acceptance defensible is not the decision itself but who made it: someone with the authority to accept that level of exposure on the organisation’s behalf, with a written reason attached to the record.

Controls belong at this stage, downstream of a specific risk that justifies them, not at the front of the process as a generic checklist applied before anyone has established what actually needs controlling. A control that exists because a template said so is answering a question nobody asked.

Mitigation strategies and other response strategies written up as prose, with no task attached, do not reduce risk. Risk response planning only counts once it produces something a person is actually accountable for doing by a date. If a gap analysis against open treatment items turns up more prose than tasks, that is usually the finding, not a footnote to it.

What does risk monitoring actually have to cover? Most descriptions of this step stop at one question: whether last quarter’s treatment plan happened. That is one part of it, and the smaller part.

A proper review asks more:

• Did the treatment happen, and did it work as intended.
• Has the risk itself changed, in likelihood, in impact, or in shape entirely.
• Does the control still function, or has it quietly stopped since anyone last checked.
• Does the underlying asset still exist, in the form the register assumes it does.
• Have new risks entered scope, emerging risks the business did not carry the last time anyone looked.

Whatever remains after treatment is residual risk. It needs the same discipline as everything upstream of it: recorded, assigned to an owner, and accepted by someone with the standing to accept it, not left unstated because the bigger risk got treated and the register moved on.

Cadence is where most programmes quietly give up. An annual review is what most of them actually run, and an annual review is not monitoring. It is an anniversary: a date on the calendar, not a response to anything that happened.

A new vendor, a new product line, an incident, or a regulatory change entering into force should each trigger a review on its own. This is continuous risk monitoring in practice, not a slogan: risk changes constantly, so continuous monitoring checks constantly, on events rather than a date. A risk register tool that only updates on a fixed date is tracking the calendar, not the business, and loses operational efficiency in the gap between the two.

Where the risk management process breaks

The five steps above can be followed correctly, in order, by a competent team, and the resulting register can still fail the first time someone outside the organisation looks at it closely. These four failure modes are why. None of them look like negligence from the inside. Each one passes an internal review, gets signed off, and sits quietly in the programme until a supervisor, an auditor, or an incident tests it directly.

The register reflects the room, not the business

A register built in a workshop captures exactly what the people in that room have experienced, and nothing else. The gaps are invisible by construction: nobody in the room can flag a risk nobody in the room has thought of, and nobody outside the room gets asked. A critical dependency that predates every attendee’s tenure, or sits in a part of the business nobody present actually touches, does not make the list, and nothing about the document signals it is missing.

The fix changes what the workshop is for, not whether it happens. Derive the risk list from the asset inventory and the business impact analysis first, then bring the room in to challenge that derivation, not to generate it from scratch. A workshop that checks a list is doing something different from a workshop that invents one.

Everything is critical, so nothing is

Marking something critical by instinct feels like the safe choice. It costs nothing to say a system matters, and saying so feels like diligence rather than guessing. Do this often enough, though, and criticality stops meaning anything: a register with forty critical items has not identified forty things that matter most. It has just moved the word critical to the top of every entry and left the actual priority underneath unresolved.

Criticality has to come from analysis, not from a reflex that treats caution as the same thing as judgment.

The point of ranking risk is to separate the handful of things that would genuinely hurt from everything else. Inflate the ranking and that separation disappears.

Treatment stalls and nobody notices

A treatment plan agreed in a Q1 meeting, with no owner, no deadline, and no reminder attached to it, is still sitting exactly where it was left by Q4. Nobody lied about its status, and nothing forces it back into anyone’s attention, so it sits marked as being addressed while nothing about it has moved since the meeting where it was decided.

This is the single most common finding in a first audit, and also the easiest one to fix. The register does not need a new column or a new process. It needs every open treatment item to convert into an actual task: a name, a date, and something that surfaces it again if that date passes with nothing done. Good intentions do not expire on their own, and without an owner and a date attached, nothing else will make them.

The process outlives the person who ran it

A risk score means something to the person who set it: the call that raised the concern, the reason a control seemed sufficient at the time. That reasoning rarely makes it into the register. Only the number does.

When that person changes roles or leaves, the register becomes a spreadsheet nobody can defend: scores nobody can explain, acceptances nobody can justify, scoping decisions made by someone no longer in the building. Rebuilding that from scratch, with an audit on the calendar, is a worse position than anyone intended.

What survives a handover is the reasoning, written down alongside the outcome. That continuity is also where independent judgment earns its cost. Copla’s in-house CISO team is one way to hold it when the register’s author moves on.

None of the five steps above are difficult to learn. No risk management solution, however well built, supplies what feeds step one on its own. What separates a register a supervisor trusts from one they quietly write off is whether the risk management strategies behind it were derived from the business or recalled from habit, and whether the reasoning behind every score and every acceptance survives longer than the person who made the call. That is what effective risk management actually looks like: not regulatory compliance treated as a formality, but a record that holds up because it was built right the first time. Book a demo to see how Copla approaches that part of the process, not just the five steps everyone already lists.