Building a Regulatory Change Management Programme

Most organisations do horizon scanning. Far fewer can show what happened to a given regulatory development after it was spotted, and that gap is what turns a monitoring function into a compliance finding.

Four stages, each with an owner

Detect. Sources, frequency and coverage. A defensible programme names its sources per jurisdiction and per regime, and records what was reviewed even when nothing was found — absence of a record is indistinguishable from absence of a review.

Assess. Does this apply to us, to which entities, to which processes, and by when? The output is a short written assessment with a named assessor. Most developments end here with “no impact”, and that conclusion needs to be recorded as deliberately as any other.

Route. Where there is impact, it becomes work owned by a business function with a due date. Legal advises; it does not implement, and programmes that blur this stall at the point where implementation requires a budget.

Evidence. Close the loop with proof: the updated policy, the changed system configuration, the training completion record, the amended contract template.

The register is the deliverable

One row per development: source, date detected, summary, jurisdictions, entities affected, assessment, assessor, decision, owner, due date, status, evidence link. This is unglamorous and it is what a supervisory authority, an auditor or an acquirer will ask to see. It is also what lets you answer “when did we know?” without an archaeology project.

Sizing it realistically

A mid-sized organisation in two or three regulated areas will process somewhere between two hundred and six hundred developments a year, of which perhaps five per cent require action. The programme has to be efficient at disposing of the ninety-five per cent, because that is where the time goes. Standardised assessment templates and a materiality filter applied at detection do most of the work.

Where automation helps and where it does not

Detection and initial classification automate well. Impact assessment does not, and should not: it depends on knowledge of your own processes that no external system has. Use tooling to get from six hundred items to thirty, and spend the human time on the thirty.