Change Impact Analysis for UK Firms: Templates and Steps
Published
Change activity accounted for 17% of nearly 1,000 material incidents reported to the FCA in 2019, according to the FCA's review discussed in the UK operational-resilience policy statement. That reframes change impact analysis: the question isn't only whether a change can be delivered, but whether the firm understands everything it could disrupt.
Table of Contents
- What Change Impact Analysis Means for Regulated Firms
- An Impact Register Template You Can Copy
- How to Run the Analysis in Six Steps
- Which Documents and Actions Regulatory Changes Trigger
- Planning Impact When the Rules Are Not Final
- Following One Change From Notice to Evidence
- Confirm Your Register Before the Next Change
What Change Impact Analysis Means for Regulated Firms
A payment firm replaces its hosting provider. Procurement updates the contract, but the same decision also affects the outsourcing policy, recovery systems, the person responsible for incident escalation and an answer already submitted in an authorisation application.
Change impact analysis is the structured work of identifying affected services, documents, controls, systems, dependencies and people before implementation. It records what needs to happen, who approves the conclusion and what evidence demonstrates that the revised arrangement works.
The FCA review examined more than a million production technology changes across financial-services firms. Its assessment went beyond technical delivery to consider incident severity, customer impact and duration. That's the right distinction for management: a completed deployment isn't necessarily a controlled change.
Why document mapping isn't enough
A document list tells you where words might need changing. An authorisation-readiness control asks whether management can substantiate those words through contracts, working systems, assigned responsibilities and credible financial assumptions.
Say the business plan describes an internal monitoring team, but a supplier now performs the activity. The wording hasn't changed, yet the underlying fact has. Reviewing only recently edited documents would miss the discrepancy.
The same reasoning applies to a financial crime risk assessment: a new customer group or delivery channel should prompt scrutiny of the controls supporting the assessment, not merely its description.
Practical rule: Assess the business fact that changed, not just the document someone opened.
For broader workflow context, Visbanking's regulatory change management guide is a useful companion to an artefact-level assessment. Keep the distinction clear: change management organises the response; impact analysis establishes its scope and consequences.
The method rests on operational-resilience mapping and applicable regulatory notification regimes. Together, these connect service delivery, ownership, evidence and deadlines, making impact analysis an operational-control discipline, not only a project-management task.
An Impact Register Template You Can Copy
Use an impact register as the working record from identification to closure. Copy these columns into Excel or Google Sheets, then add a separate row for each affected artefact so that a completed policy update doesn't hide an unfinished system test.
Impact register fields and what to record
| Field | What to record | Example entry |
|---|---|---|
| Change reference | Unique ID, source and date identified | CLOUD-REPLACEMENT; approved supplier decision; identification date recorded |
| Change type | Textual, changed interpretation, new obligation or removal | New obligation: outsourced function moves to a new provider |
| Planned or unplanned | Whether notice can be given before the change | Planned: provider replacement scheduled for next quarter |
| Affected artefacts | Policies, procedures, application answers, reports and data fields | Outsourcing register, business plan technology section, incident procedure |
| Systems and dependencies | Services, data flows and third parties affected | Payment processing service and cloud hosting provider |
| Accountable owner | Named individual who approves the impact conclusion | Named senior manager responsible for outsourcing |
| Evidence required | What proves the change is embedded, not only reworded | Signed contract, tested failover and updated control owner list |
| Notification and deadline | Whether the regulator must be told, and by when | FCA notice without undue delay where the applicable outsourcing duty is triggered |
| Confidence level | Confirmed, likely or possible | Likely: scope depends on how the business model is read |
| Residual risk and status | Remaining exposure and open actions with dates | Medium: failover untested; action deadline entered in change calendar |
Identify, scope and prove
The identification fields establish why the assessment exists. Keep the original regulatory publication or internal decision alongside the register, and distinguish planned changes from unexpected events.
The scope fields connect the change to its consequences. Link each artefact to its controlled version, not a filename alone, and name an individual rather than a department as the accountable owner.
The proof fields establish whether the work is ready for approval. Record the evidence location, notification decision, remaining uncertainty and open actions, including who must resolve them.
Change type matters because the work differs. A textual correction may need editorial review; a changed interpretation may require revised calculations; a new obligation may need a new control; a removal may require safe decommissioning.
Make dependencies visible
The Bank of England's banking regulatory-reporting guidance describes reporting through PRA processes and FCA RegData, alongside coordination on data definitions and systems. That's why a reporting change should be traced through source fields, calculation logic, validation, approvals and downstream submissions.
A business fact can appear in several places. For example, the identity of an outsourced operator may appear in the business plan, supplier register, application answers and recovery procedure.
For spreadsheet organisation, Spreadsheet Upgrade's guide to track compliance obligations in a spreadsheet provides useful context. Add controlled evidence links and filters for owner, deadline and status.
Review open rows at each change meeting. A usable register has no blank owners, no unresolved confidence marker without a review date, and a recorded notification conclusion for every planned change, including a reason where notice isn't required.
How to Run the Analysis in Six Steps
Run the analysis against the proposed operating arrangement, not a collection of documents in isolation. Keep the source, assessment and approval trail together so another reviewer can understand the decision without reconstructing conversations.
Establish the change and its reach
- Log the change at source. Save the regulator's text or internal decision, its date and the date the firm became aware of it, then mark the change as planned or unplanned. Don't assume implementation starts the notification clock: the applicable trigger may instead concern awareness, a proposal or an unexpected occurrence.
- Classify the change type. Decide whether the change is textual, interpretative, a new obligation or a removal, and describe the practical consequence. Bring the business plan, financial information, policies and application answers into the review so classification doesn't rest on a policy drafter's view alone.
- Trace requirements to artefacts and owners. Build a requirement-to-evidence matrix linking each affected requirement to procedures, application answers, reporting fields, systems and accountable individuals. Follow the underlying process using a business analysis process model, rather than stopping when you find a document containing the relevant phrase.
Verify, decide and maintain
- Test operational reality. Compare the proposed description with contracts, system configuration, control-owner records and evidence that staff can perform the control. A signed policy proves approval of wording; it doesn't prove that access rights, escalation routes or recovery arrangements have been implemented.
- Set deadlines and notice decisions. Identify the applicable legal trigger, record the recipient and required content, and calculate the deadline from the correct event. Assign an accountable decision-maker and make the notice decision visible before approving implementation, rather than leaving compliance to discover it at release review.
- Record decisions and re-analysis triggers. Save the conclusion, supporting evidence, unresolved exposure, approval and the circumstances that would reopen the assessment. A changed supplier, revised business activity, new regulatory interpretation or failed test should trigger review of the affected material, not merely a comment in meeting minutes.
Closure means the reviewer can establish what changed, why it was acceptable and what evidence supported the decision.
In our authorisation process, the second step brings the business plan, financial information, policies and application answers together. We review the documents, resolve findings and revisit affected material when facts change.
That discipline also helps management prepare consistent explanations. If a responsible person can't explain how the control works, who performs it and what happens when it fails, there's still an evidence or implementation question to resolve.
At closure, every affected row should have an owner, an evidence reference and a closing date. Where management accepts residual risk, record its reasoning and approval separately from the statement that the implementation tasks are complete.
Which Documents and Actions Regulatory Changes Trigger
A regulatory change can affect an application, a live operating arrangement, or both. Start by identifying the firm's legal status and the event that triggers action. Then trace the change into the records, owners and operational evidence it affects. An application update and a notification about a live outsourced function are separate duties, with different triggers.
Under regulation 20 of the Payment Services Regulations 2017, applicants must report material changes to submitted information without undue delay. This includes discovering that information is incomplete or materially inaccurate, and reporting likely changes as soon as the applicant becomes aware of them. The regulation separately addresses changes to outsourced functions, or the persons performing them, at authorised payment institutions.
Regulatory changes, affected artefacts and required actions
| Regulatory change | Affected artefacts | Required action | Notice or timing |
|---|---|---|---|
| Material change to information in a payment services application | Application narrative, business plan, risk assessment | Update and report to the FCA | Without undue delay; likely changes reported once known |
| Change to outsourced functions or the persons performing them at an authorised payment institution | Outsourcing register, operational procedures, governance responsibilities | Review the change and notify the FCA | Without undue delay |
| Planned material change at an AIFM | Notified operating model, delegation structure, governance records | Give written notice and assess the impact before execution | At least one month before implementation |
| Unplanned material change at an AIFM | Original notification and the notified matters affected | Notify and escalate | Immediately after occurrence |
| Change affecting a notified registration under the relevant registration legislation | Submitted answers, supporting documents, evidence of the change | Notify, update evidence and answer FCA information requests | Promptly, within any period the FCA sets |
| Deletion of PRA banking reporting templates | Reporting procedures, shared calculations, data feeds, controls | Retire affected reporting only after checking dependencies and recording the rationale | By the applicable reporting-change effective date |
| Change to an important business service | Mapping of people, processes, technology, facilities and third parties | Assess and test continued delivery within impact tolerance | Under the applicable resilience framework and change approval process |
| Proposal by a recognised body to make regulatory provision | Permissions, governance, member or client obligations, disclosures | Give written notice to the appropriate regulator | Without delay, subject to applicable exceptions |
Planned, likely and already occurred
The trigger determines the clock. For AIFMs, regulation 61 of the Alternative Investment Fund Managers Regulations 2013 requires written notice of a planned material change at least one month before implementation. An unplanned material change must be notified immediately after it occurs. Build the advance deadline into the approval workflow, so implementation cannot proceed without the required notice being considered.
The relevant registration legislation enacted in 2025 requires prompt notification of material changes affecting a registration notification. It also permits the FCA to request further information within a specified period. Keep the submitted answers versioned, alongside evidence that supports any supplementary response, so the firm can explain what changed and when.
For recognised bodies, section 300B of FSMA requires notice without delay of proposals to make regulatory provision, subject to applicable rules on exceptions and notice requirements. A routine reporting cycle does not replace the legal trigger.
Removal still requires implementation work
The PRA's competitiveness and growth report reports that 37 banking reporting templates were deleted effective 31 December 2025, with an estimated £65.9 million net reduction in delivered reporting burden and a further £32.6 million of changes in progress for 2026 and later.
Removing a reporting requirement does not automatically remove the systems and controls built around it. Before switching off a return, check whether its calculations, data feeds or controls support other obligations. The FCA compliance requirements provide context for that review, but the firm still needs to identify the specific legal trigger and action. A document that remains unchanged while actual operations shift can be a higher-risk gap than a document visibly marked for revision.
Planning Impact When the Rules Are Not Final
An affected-or-unaffected checkbox is inadequate when regulatory scope or implementation arrangements remain unsettled. Management needs a defensible working position, a confidence level, a decision deadline and interim controls.
The FCA's implementation information for the new cryptoasset regime states that commencement is expected on 25 October 2027, with applications scheduled from 30 September 2026 to 28 February 2027; firms may need new authorisation or a variation of existing permissions. Treat those as published implementation expectations, not a guarantee of an individual firm's authorisation timetable.
The FCA's cryptoasset-regime policy statement identifies trading platforms, intermediaries, custodians, stablecoin issuers and firms arranging staking as activities requiring authorisation under the new regime. It also connects authorisation to Threshold Conditions, appropriate systems and controls, and reporting requirements.
Separate operating facts from intended arrangements
An application should distinguish already operating, approved but not implemented, and still to be established. Otherwise, a description of the intended business can accidentally imply that a control exists today.
We prepare policies and operating arrangements that distinguish current arrangements from those the business still needs to establish. We also identify missing evidence, unresolved questions and decisions requiring further client involvement.
Scenario-based impact register for uncertain perimeter
| Scenario | Confidence level | Interim action | Re-analysis trigger |
|---|---|---|---|
| Activity clearly within the new perimeter | Confirmed | Build controls and evidence now | Final rules published |
| Activity depends on how the business model is interpreted | Possible | Document both readings and the chosen position with reasons | Regulator guidance or consultation outcome |
| Arrangement not yet legally required but needed for a credible application | Likely | Mark as to-be-established, with owner and date | Scheduled application-window opening |
| Transitional provisions not yet published | Unknown | Set a decision deadline and avoid irreversible spend | Publication of transitional rules |
Use the table only where the scenario reflects the actual publication status. Don't label transitional provisions unknown if they've already been published, or treat an internal interpretation as confirmed merely because management prefers it.
Decision test: What evidence would demonstrate that the proposed arrangement is operating, rather than simply described?
An unchanged document that no longer matches operations can be the highest-risk impact. For example, an existing custody procedure may still describe a responsibility that has moved to a different entity, leaving the application narrative apparently consistent but factually wrong.
Prioritise reversible work, such as mapping dependencies, allocating responsibilities and collecting evidence. Before committing to a particular architecture or outsourcing structure, ask what would need to be undone if the final perimeter differs, and identify which commitments should wait.
Following One Change From Notice to Evidence
Consider a hypothetical UK authorised payment institution replacing a critical cloud hosting provider. It also has an application under consideration, so the team must assess both ongoing outsourcing duties and the accuracy of information already submitted.
The sequence below uses decision points rather than invented statutory deadlines. Each event should receive its actual date in the register.
From supplier decision to implementation gate
When management selects the provider, the change owner logs a planned migration and records a confirmed outsourcing impact. The team opens separate rows for the outsourcing register, business plan technology section, service-dependency map, incident procedure and application outsourcing answers.
When the material change becomes foreseeable, compliance assesses the applicable notification duties rather than waiting for migration. The notice record captures what management knows, what remains conditional and which submitted statements require correction.
Before implementation approval, operations tests a severe-but-plausible failure of the new provider. The assessment measures outage duration, affected users, transaction volumes, payment values and recovery capability against the service's approved tolerance where the resilience framework applies.
The PRA's operational-resilience framework required relevant firms to identify important business services and set impact tolerances by 31 March 2022, with the framework fully operational by 31 March 2025. For a payment firm outside that framework's direct scope, don't present PRA obligations as automatically applicable; use the mapping and testing method as a control design where appropriate.
Assemble the evidence package
The owner retains the signed contract, dependency map, test results, incident contacts, notice record and approval decision. Distinguish a successful recovery test from an exercise that merely confirms staff know the procedure, using the principles in evidence explained.
External alerts serve a different purpose from outgoing regulatory notices. For comparison, Dutiful's notifications when customs regulations change illustrate an incoming change-notification service; an alert doesn't establish whether the payment firm must notify its regulator.
The example exposes avoidable gaps:
- Contract-only completion: Procurement signs the agreement, but nobody updates the outsourcing register.
- Late notice assessment: Compliance first considers notification after go-live.
- Paper-only recovery: The team approves a failover plan without evidence of execution.
Copy the sequence into the change calendar, attach evidence at each decision point and prevent release approval while critical findings remain unresolved.
Confirm Your Register Before the Next Change
Apply these yes-or-no tests to the live register. A no should produce an assigned action, not an unexplained exception.
- Is the change identifiable? Can a reviewer find its ID, original source and accountable owner?
- Is the scope complete? Are affected documents, systems, controls and third parties listed?
- Do application answers match operations? Have you checked the relevant contract and control-owner list?
- Are notice deadlines actionable? Does the calendar capture applicable advance-notice and without-undue-delay duties?
- Is evidence available? Can the reviewer inspect supporting records, including executed failover tests where relevant?
- Is uncertainty managed? Does each unresolved interpretation have a confidence level, decision date and re-analysis trigger?
- Has someone checked consistency? Has a second reviewer compared the affected documents and resolved conflicting statements?
Turn findings into scheduled work
We check consistency across application documents, address findings and prepare the identified package for internal and client approval. That approval is separate from the regulator's decision: regulatory decisions remain with the relevant authority, and approval or decision dates aren't guaranteed.
Choose the three live changes with the most open register rows and run the six-step analysis on each this week. Record the findings, evidence gaps and decisions in the register, assign owners and fix the date of the next change meeting.
Glentorion helps financial and crypto businesses connect operating changes to application documents, responsibilities and supporting evidence. Visit Glentorion to arrange a Discovery Call covering your intended activity and market, current preparation stage, available material and the questions holding the work back.
- change impact analysis
- regulatory change
- impact assessment
- FCA authorisation
- operational resilience
