Regulatory Change Management Is Still Too Reactive
Regulatory change comes up in most conversations I have with compliance and risk teams. Not whether a process exists; most organisations have one. The real question is whether it is working the way it should.
At a basic level, it is simple.
Track what is coming, decide what applies, and update your controls and processes. That should, in theory, keep organisations ahead of change. It often does not.
Most teams have the process; the challenge is how it is used
Scope expands beyond what is really needed. Requirements get treated the same as core, day-to-day obligations.
Volume builds.
Effort increases.
Clarity drops.
The structure is there. It is just not being applied in a practical way.
Timing matters more than it should
Horizon scanning is meant to give teams a head start. But a lot of the real work still kicks off once regulations are finalised. At that point, it becomes about assessing impact, mapping requirements, updating controls. There is less space to step back and ask: what matters here?
Where it starts to break down
Even when requirements are captured, they do not always translate cleanly. The connection between the requirement, the underlying risk, and how the business operates is not always clear. The process keeps moving, but it becomes more about tracking change than really understanding it.
What is starting to work in practice
This is not about adding more steps. It is about tightening what is already there.
A few things that are making a difference:
→ Cutting scope early
Define clear criteria for what gets pulled into scope (e.g., business model, jurisdiction, products).
Not everything needs to be included.
→ Tiering obligations by risk
Group requirements into simple tiers (high / medium / low).
Align effort, controls, and testing to the level of risk.
→ Starting interpretation earlier
Use draft guidance, consultations, and regulator signals.
Do not wait for final publication to begin thinking about impact.
→ Mapping to risk before controls
Be clear on what risk a requirement is addressing.
Then design or map the control rather than the other way around.
→ Connecting to how the business operates
Identify where this shows up day to day.
Who owns it, what process it sits in, and how it is executed.
→ Keeping the inventory usable
If it is too complex to explain, it is too complex to manage.
Simplify structure, naming, and ownership so teams can use it.
The goal is not to track more change. It is to identify what matters earlier, apply the right level of effort, and connect requirements to how the business operates.
For more practical insights on organisational transformation, follow CMBYND on LinkedIn and subscribe to our newsletter CMBYND Thinking.