When one policy changes, what else needs to change?

Changing a policy is relatively straightforward. Understanding everything that change affects across a large organisation is another matter entirely.

I’ve always found it interesting how much attention organisations give to developing and approving policies, compared with understanding what happens after those policies change.

There’s usually a well-established process. Someone identifies a requirement, drafts an amendment, consults the relevant stakeholders, obtains approval and publishes the updated policy.

The document has been reviewed. The necessary approvals are recorded. The change is communicated.

Job done. Or at least that’s how it can appear.

But the question I’d be asking is: what else needs to change because that policy has changed?

It’s a much harder question to answer, particularly in large organisations where policies, procedures, responsibilities and systems have evolved over many years.

And it’s where some of the most important operational problems begin.

The policy is only one part of the picture

Take something relatively common in banking.

A bank changes its lending policy to introduce additional approval requirements for a particular category of loan.

The policy team makes the amendment, the appropriate governance process is followed and the revised document is published.

But the change doesn’t stop there.

It might affect the delegations held by relationship managers, the way credit teams assess applications, the instructions used by lending operations and the controls that risk teams are responsible for monitoring.

There may be training material, approval matrices and system rules that also need to reflect the new requirements.

Each of these could sit with a different team, in a different system, with a different person responsible for maintaining it.

Now, the bank will almost certainly have change management processes in place. I’m not suggesting otherwise.

The difficulty is knowing whether everyone and everything affected by the change has actually been identified.

You can have a perfectly good process for updating a document. You can also have a perfectly good process for assigning follow-up tasks.

But those processes are only as effective as your understanding of what needs to be updated in the first place.

And that understanding is often much less complete than organisations would like to believe.

The problem is what you don’t know is connected

Large organisations are incredibly interconnected, but they don’t always have a clear picture of those connections.

A policy in one business unit might determine how another team handles exceptions. A delegation might be referenced in several procedures. A control might depend on an operational step that is documented somewhere else entirely.

Most of these relationships have developed for perfectly sensible reasons.

The business has grown. New products have been introduced. Regulations have changed. Teams have been restructured. Technology has been replaced.

Over time, different parts of the organisation build up their own ways of managing the requirements that apply to them.

And for the most part, things continue to work.

The difficulty becomes apparent when something changes.

Someone updates a policy without knowing that another department has built a procedure around the previous version. Or an approval authority changes, but an operational instruction still directs employees to the former decision-maker.

The policy itself may be completely correct.

The inconsistency sits somewhere else.

This is what I think gets overlooked in discussions about policy governance. The greatest challenge isn’t always managing the policies themselves. It’s understanding the relationships between them and everything else the organisation does.

You can’t assess the full impact of a change if you can’t see what depends on it.

Why organisations end up relying on a handful of people

One of the realities of large businesses is that a lot of operational knowledge still sits with individuals.

There will be people who know that a particular policy affects three other processes. People who remember why an exception was introduced. People who know which team needs to be consulted before a requirement is changed.

They become the people everyone turns to when something complicated needs to be worked through.

That experience is invaluable. But it also tells us something about the organisation.

If you need to find the right person to understand how your own policies and procedures fit together, how much of that understanding is actually held by the business?

And what happens when that person leaves, changes roles or simply isn’t involved in the next review?

We’ve been discussing the consequences of major banking restructures recently, and I think this is one of the less visible risks. Organisations can remove or consolidate management positions, but the operational knowledge those people have accumulated doesn’t automatically transfer with their responsibilities.

The same problem exists in normal day-to-day operations, without a major restructure.

People move on. Teams change. Documentation gets updated in one area but not another. Eventually, the organisation has to work backwards to understand why something is done the way it is.

That’s an expensive way to manage knowledge, particularly when you’re dealing with thousands of documents and requirements.

When the policy says one thing and operations do another

The consequences aren’t necessarily immediate or obvious.

In fact, that’s part of the problem.

An outdated procedure might be followed for months before anyone realises it no longer reflects the current policy.

Different teams might interpret a requirement in slightly different ways, each believing they’re operating correctly.

A change in responsibility might be reflected in the organisation chart but not in the approval or escalation instructions employees actually use.

None of this necessarily involves someone deliberately doing the wrong thing.

Often, people are simply following the guidance available to them.

And that raises a question about where responsibility really sits.

If an employee follows an approved procedure that conflicts with an updated policy, is that an individual performance issue? Or is it evidence that the organisation hasn’t managed the relationship between its requirements effectively?

I’d argue that leaders need to be particularly interested in the second question.

It’s relatively easy to tell someone they should have followed the policy.

It’s much harder to explain why the organisation was still providing them with inconsistent instructions.

For regulated businesses, these inconsistencies can become more than operational inefficiencies.

APRA’s CPS 230, for example, places significant emphasis on effective operational risk management, internal controls and understanding the dependencies that support critical operations.

It also recognises change management as a source of operational risk.

The standard doesn’t suggest that every policy amendment presents a major risk, nor does it prescribe how organisations should manage document relationships.

But it reinforces an important principle: having policies and controls in place is not enough. They need to work effectively within the organisation’s actual operations.

That’s the part that matters.

More documentation doesn’t necessarily solve the problem

I suspect most executives would be surprised by just how much time their organisations spend reviewing, updating, reconciling and interpreting internal documentation.

There’s an enormous amount of effort involved, particularly in regulated industries.

And when gaps are identified, the instinct is often to introduce another review, another register or another process.

Sometimes that’s necessary.

But I think we need to be careful that we’re not simply adding more administration to manage a problem we haven’t properly understood.

Let’s say a policy change has been approved and five related procedures have been identified for review.

The owners receive their tasks. The changes are completed. Everything is recorded, and the project is closed.

That’s a successful process if those were the five procedures that needed attention.

But what if there were eight?

How would anyone know?

That’s the distinction I keep coming back to.

Knowing that you’ve completed all the work you’ve identified is not the same as knowing you’ve identified all the work that needs to be done.

It’s a relatively simple observation, but I think it exposes a significant weakness in how many organisations approach change.

We have become very good at tracking activities.

We’re not necessarily as good at understanding dependencies.

We need to think differently about change

I don’t believe the answer is to make policy teams responsible for even more manual analysis.

Nor is it realistic to expect every policy owner to understand all the operational implications of a change across an entire organisation.

The complexity is simply too great.

What needs to improve is the organisation’s ability to understand how its own requirements connect.

Imagine being able to examine a proposed policy amendment and identify the procedures that reference it, the delegations that may be affected, the controls that depend on it and the business units that need to consider the implications.

Not because one person happens to remember those relationships, but because the organisation has a more systematic way of understanding them.

That wouldn’t eliminate the need for judgement.

Someone would still need to decide whether a particular procedure actually requires amendment, whether an apparent inconsistency is valid or how a regulatory requirement should be interpreted.

But it would give those people a much better starting point.

Advances in AI and information analysis are creating opportunities to examine these relationships in ways that have traditionally been difficult and labour-intensive.

The opportunity isn’t simply to search documents faster.

It’s to identify potential connections, inconsistencies and consequences that might otherwise be missed.

That’s a much more useful conversation than asking how quickly technology can summarise a policy.

And it matters beyond regulated industries. Any large organisation with multiple business units, established processes and changing responsibilities faces versions of the same problem.

The bigger issue is keeping organisations aligned

Perhaps the most important point is that this shouldn’t only become a priority when something major happens.

Organisations change constantly.

New regulations are introduced. Products evolve. Systems are upgraded. Responsibilities shift. Processes are improved.

Some changes are significant. Others seem relatively minor.

But each one has the potential to affect requirements elsewhere in the business.

If we only examine those connections during major transformation projects or periodic policy reviews, we’re always playing catch-up.

I think organisations need to become much better at maintaining an ongoing understanding of how they operate.

Not continually redesigning everything. Not reviewing every policy every time something changes.

Just being able to identify where change has consequences, where requirements may no longer align and where someone needs to take a closer look.

The objective isn’t more governance for its own sake.

It’s better visibility, better decisions and less reliance on people manually piecing together how the organisation works.

A question worth asking

The next time a significant policy amendment goes through an organisation’s governance process, I’d encourage the executive responsible to ask one additional question.

We know the policy has been updated.

How confident are we that everything affected by the change has been identified?

If the answer depends on who happened to be consulted, which documents someone remembered to check or how much experience the policy owner has, there’s probably an opportunity to improve the way the organisation manages change.

Because updating the policy was never really the end goal.

The goal was to change how something happens in the business.

And until the organisation understands what that change means for the people, processes and decisions that depend on it, it’s difficult to know whether the job is actually done.

References

• Australian Prudential Regulation Authority, Prudential Standard CPS 230 — Operational Risk Management.
• Australian Prudential Regulation Authority, Prudential Practice Guide CPG 230 — Operational Risk Management.