What is regulatory change management?

Regulatory change management (RCM) is the structured process by which a supervised financial institution takes an already-detected regulatory change into internal implementation and closes that implementation out in an evidenced way. It is the “act on it and prove it” phase: RCM takes over exactly where detection ends — after a requirement has been captured and classified as relevant — and drives it through impact assessment, assignment of ownership, implementation of the necessary control, policy, process and system changes, and on to sign-off and audit-ready evidence.

The scope of RCM is deliberately confined to execution. It does not watch the rule universe (that is regulatory monitoring) and does not detect emerging signals (that is horizon scanning); it receives a discrete, sufficiently binding change item and converts it into tracked, deadlined, owned work. Typical triggers are a regulation published in the Official Journal, a finalised technical standard (RTS/ITS), a new guideline, or a supervisory letter with a concrete implementation demand. The end state is not “implemented” but “implemented and evidenced” — the condition in which the institution can show an inspection what it did and when.

The three disciplines are successive stages of a single pipeline, not competing approaches. Regulatory monitoring is the umbrella practice of continuously watching the whole relevant rule universe — both binding obligations and new developments. Horizon scanning is the forward-looking subset of it: the deliberate detection of emerging, not-yet-binding signals before they become operational reality. Both are detection — they answer “what has changed?” and “what is coming?”. Regulatory change management answers the third question: “what exactly must we do, by when, and how do we evidence it?”

The handoff point is precise: detect → RCM. Once monitoring has captured, assessed and routed an item to the responsible function, and the requirement is binding enough to justify implementation effort, it leaves the sensing layer and enters the implementation workflow. RCM is therefore explicitly not detection — it is the execution at the end of the chain. Nor should it be conflated with RegTech: RegTech (regulatory technology) is the software category used to automate both detection and implementation — the toolkit, not the activity itself ^[3].

A robust RCM process runs through five stages. First, impact assessment: which business lines, products, processes and systems does the change touch, and how material is it? Second, gap analysis: where exactly does the current state diverge from the new requirement — which control, policy or system capability is missing or must be adapted? Third, implementation: the identified gaps are translated into concrete actions with owners and deadlines and carried out. This is precisely the expectation the EBA Guidelines on internal governance set out — “a process to regularly assess changes in the law and regulations applicable to its activities” ^[2].

Fourth, validation: it is tested and signed off that the implemented changes actually satisfy the requirement — not merely that a task was marked “done”. Fifth, audit-ready evidence: across the whole run an immutable, timestamped audit trail is written — when the change was detected, how it was assessed, to whom it was assigned, with which actions it was implemented and with what outcome it was validated. As with monitoring, what counts in an inspection is not that implementation happened but that it can be evidenced. Evidence reconstructed “on request” typically fails this test.

RCM is not a stand-alone project plan but embedded in the institution’s governance model. In the widely used three-lines-of-defence model, the first line — the business — carries operational responsibility for implementing the change in its processes and controls. The second line — compliance and risk management — assesses the impact, approves and oversees implementation; the EBA Guidelines require the compliance function to “assess the possible impact of any changes in the legal or regulatory environment on the institution’s activities and compliance framework” ^[2]. The third line — internal audit — independently tests whether the process itself works.

Clear ownership and board-level line of sight are not optional here. The EBA Guidelines explicitly task the management body in its supervisory function with overseeing a “well-documented compliance policy” and require the compliance function to report to the management body on compliance risk and its management ^[2]. For RCM this means: a change item needs a named owner, a defined escalation path and a documented reporting line to the board — otherwise the traceability supervisors require is absent.

A documented change process is not a voluntary best practice but an implicit supervisory expectation. Its canonical basis is the Basel standard “Compliance and the compliance function in banks” (2005): the compliance function is to advise senior management on the applicable laws, rules and standards, “including keeping them informed on developments in the area” ^[1]. But advising on a development is inconsequential without a downstream process that translates it into concrete action and evidences that action — and RCM is precisely that process.

The EU supervisory authorities make this expectation concrete. The EBA Guidelines on internal governance under CRD expressly require a process to regularly assess changes in the applicable laws and regulations, and a documented compliance policy overseen by the management body ^[2]. A documented change process is also the practical core of instruments such as the SREP, the ICAAP and — in the insurance sector — the ORSA: all three presuppose that an institution can demonstrate how it responds to regulatory and risk change. The pressure is compounded by the volume of binding frameworks: DORA (Regulation (EU) 2022/2554) has been fully applicable since 17 January 2025 ^[4] and MiCA (Regulation (EU) 2023/1114) creates a harmonised framework for crypto-asset service providers ^[5] — both generating a continuous stream of technical standards to implement.

RCM can be run in spreadsheets and email inboxes — until volume, deadline pressure and the evidence requirement overwhelm that approach. The EBA sees RegTech explicitly as a means of making compliance and reporting processes in the EU financial sector more efficient and more effective ^[3]; the core question is therefore not whether but what depth of tooling. The build-vs-buy trade-off rests on a simple test: a tool that joins detection (monitoring/horizon scanning) and implementation (RCM) in one continuous, immutable audit trail — from first signal to validated measure — addresses the real problem; a tool that covers only one stage merely moves the break to somewhere else.