Why do IRM implementations stall, and what does remediation involve?
IRM implementations most often stall because the platform was configured before the risk taxonomy, control library and ownership model were actually settled, so the configuration encodes assumptions nobody has confirmed. Remediation is usually not a technology problem: it means going back to settle the taxonomy and ownership first, then reconfiguring the platform to match, rather than continuing to patch the original configuration. If the risk categories in the platform were finalised before every risk owner confirmed they recognised their own risk in them, the implementation was sequenced wrong regardless of how the software performs.
Published · Updated
Maximilian Bazzi, Founder and CEOWhat "stalled" usually looks like in practice
A stalled implementation rarely looks like an outright failure. It looks like a platform that went live on schedule, technically works, and is used by almost nobody the way it was intended: risk owners maintain spreadsheets alongside it, reporting is manually reconciled before board meetings, and the configuration has not meaningfully changed since launch because nobody is confident enough in it to touch it.
Why the sequencing is the actual cause
Implementation projects are usually scoped and timed around the platform going live, which creates pressure to configure early and settle taxonomy and ownership questions in parallel, or after. Once the platform is configured, changing the taxonomy underneath it becomes expensive, so organisations tend to adapt the taxonomy to fit what was already configured rather than the other way round. That is the point at which an implementation stops reflecting how the organisation actually manages risk.
What remediation actually involves
Remediation starts with the taxonomy and the ownership model, not with the platform. That means confirming, with the actual risk owners, whether the categories and control structure reflect how they work, and whether every control and risk has a named owner who accepts it as theirs. Only once that is settled does reconfiguring the platform make sense, because otherwise the same mismatch gets rebuilt in the same tool.
Where teams commonly run into difficulty
The difficulty is usually political rather than technical: reopening the taxonomy after a platform has already gone live can look like admitting the original implementation failed, which makes it tempting to keep patching the configuration instead. That patching rarely closes the actual gap, because the underlying taxonomy and ownership questions are still unresolved.
How Bazzi Consulting helps
We diagnose whether a stalled implementation is a taxonomy and ownership problem or a genuine platform problem, and lead the remediation from whichever it turns out to be. See making the framework run.