How Technology Change Creates Risk
Technology change can improve resilience, but it can also introduce new systems, integrations, suppliers and data dependencies. Financial-services organisations should assess how each material change affects important business services, test realistic failure scenarios and make sure the whole service can recover within acceptable limits.
Most of this work is designed to make the business stronger.
But every major change can also create new operational risk.
A service that was well understood before a transformation may rely on a very different set of systems, integrations, data flows and suppliers afterwards.
The new technology may work exactly as designed.
But the business service as a whole may still be less resilient than expected.
That creates an important question:
When the technology changes, do we understand how the resilience of the service changes with it?
What is operational resilience in financial services?
Operational resilience is the ability to keep important business services running when disruption occurs, or to recover them before the disruption causes unacceptable harm.
The FCA’s operational resilience guidance describes resilience as the ability to prevent, adapt and respond to, recover and learn from operational disruption.
For firms within the scope of the FCA rules, this includes identifying important business services, setting impact tolerances and understanding the people, processes, technology, information and third parties needed to deliver them.
The important word is service.
A customer does not care that one application is still online if they cannot:
- make a payment;
- access an account;
- submit a claim;
- amend a policy;
- receive a pension payment.
Operational resilience therefore needs to look beyond individual applications. It needs to consider the complete service.
Why technology change can create new resilience risk
Technology transformation changes dependencies.
Imagine a service that once relied on:
Customer channel → legacy application → database → payment service
After modernisation, it might rely on:
Customer channel → API platform → cloud service → new application → data service → third party → payment service
The new architecture may be more flexible and easier to change. But it is also different. New dependencies may include:
- integrations;
- cloud services;
- identities and access controls;
- data pipelines;
- external APIs;
- managed-service providers;
- automated processes.
If those dependencies change, the resilience model needs to change as well.
Otherwise, the organisation risks testing yesterday’s service while running today’s.
Resilience mapping should move with the technology
For firms in scope, operational-resilience mapping identifies the resources needed to deliver an important business service.
That map should not become a document that is created once and then forgotten.
A major project may replace an application, change a supplier, reroute data or introduce a new integration.
Each change can alter how the service fails and how it recovers.
The FCA’s March 2026 review of firms’ operational-resilience work found good progress, but it also highlighted areas where firms can continue to improve mapping, scenario testing and their understanding of service dependencies. Read the FCA’s 2026 operational-resilience observations
A useful rule for major projects is:
Every material technology change should identify what has changed in the service dependency map.
Start with the business service, not the system
When a new platform is introduced, it is natural for the project to focus on whether that platform works. That is necessary. It is not enough.
Suppose a bank changes the technology supporting payments.
Testing should not stop at:
Does the new application work?
It should also ask:
Can the customer still complete the payment from beginning to end?
That means testing the application, integrations, data, external providers, exception handling and operational processes around it.
The same idea applies to insurance claims, pension payments, account access and other important services.
Impact tolerance is not the same as recovery time
This distinction is important. A technical system may recover in two hours. That does not mean the business service has recovered in two hours.
There may still be:
- queued transactions;
- data to reconcile;
- failed customer requests;
- manual work to complete;
- downstream systems to restart.
An impact tolerance considers how much disruption the business service can withstand before unacceptable harm occurs.
A technical recovery target considers how quickly a system should be restored.
Those measures are related, but they are not the same.
When technology changes, delivery teams should therefore ask:
Can we restore the service, clear the backlog and deal with any customer impact within the acceptable limit?
That is a stronger test than simply restarting an application.
Test failure, not only success
Most project testing proves that the new system works when things go as planned.
Resilience testing asks what happens when they do not. Useful scenarios might include:
- an integration failing;
- a cloud service becoming unavailable;
- a third party stopping service;
- data arriving late or incomplete;
- authentication failing;
- a deployment introducing an error;
- capacity falling below demand.
The point is not to predict every possible incident. It is to understand how the service behaves under pressure.
Recovery procedures should also be exercised. A recovery plan that has never been tested is still an assumption.
Technology change itself needs control
Google’s Site Reliability Engineering work found that roughly 70% of outages in its own environment were linked to changes in live systems.
Google’s response was not to avoid change. It was to make change safer through automation, progressive rollout, fast detection and safe rollback. Read Google’s SRE guidance on change management
That principle matters in financial services.
Operational resilience should not mean making every technology change slow and difficult.
The aim should be to make change: smaller, observable and recoverable.
That can include automated testing, staged releases, better monitoring and clear rollback or recovery plans.
For more on this, see DigX’s How to Deliver Technology Change Without Disrupting Operations.
Third-party resilience is part of the service
Financial-services technology often depends on external organisations.
These may include:
- cloud providers;
- SaaS platforms;
- payment providers;
- data services;
- outsourcing partners;
- Managed Services providers.
A new supplier may improve capability and resilience. It can also introduce another dependency. The organisation therefore needs to know:
- which important services depend on the provider;
- what happens if the provider is unavailable;
- what information will be available during an incident;
- what alternative arrangements exist;
- how recovery will be coordinated.
Using an external provider does not remove the need to understand how the business service will remain resilient.
This becomes especially important during transformation, when several new third-party dependencies can appear at once.
Monitor whether the service works, not just the technology
Technology monitoring can show that servers, applications and APIs are available. That does not always mean the customer journey is working.
Imagine that:
- the API is online;
- the application is online;
- the database is online;
but transactions are failing between them.
The technology dashboard could look healthy while customers are still affected.
Where possible, monitoring should therefore include business-service measures. For example:
- payments completed;
- claims submitted;
- policies updated;
- transactions reconciled;
- processing queues;
- data freshness.
This helps teams understand the effect of a technical problem rather than simply detecting that one component has failed.
Rollback needs to consider the business state
Rollback can also be more complicated than it appears.
Returning to the previous software version may not undo everything that happened after the new version was released.
Transactions may already have been processed. Data may have changed.
Downstream systems may have received information. Customers may have been contacted.
The better question is therefore:
Can we return the business service to a safe state?
That may require data reconciliation, compensating transactions or controlled manual processing as well as technical rollback.
Those steps should be understood before a major release.
Make resilience part of the go-live decision
This is where operational resilience becomes a delivery issue rather than a compliance exercise.
Before approving a major technology change, the programme should be able to explain:
- Which important business services are affected?
- Which dependencies have changed?
- Has the service map been updated?
- Can failure be detected quickly?
- Have realistic failure scenarios been tested?
- Can the whole business service recover within acceptable limits?
- Are new third-party dependencies understood?
- Is the operational team ready to take ownership?
There should also be clear accountability for accepting the answer.
Someone responsible for the business service needs to understand the residual risk, not just the project team delivering the technology.
Resilience must continue after go-live
A project can successfully launch new technology and still leave risk behind.
The operational team needs working monitoring, support access, recovery procedures, supplier contacts and enough knowledge to manage the service.
That transition should start before go-live.
DigX’s From Project to BAU: Service Transition and Hypercare looks at this problem in more detail.
The project is not truly complete if the service still depends on the people who built it every time something goes wrong.
Standing still also creates risk
There is another side to the argument. Avoiding technology change does not remove operational risk.
Older environments can contain:
- unsupported systems;
- fragile integrations;
- manual processes;
- undocumented dependencies;
- knowledge held by a small number of people.
So the objective should not be to make as little change as possible.
It should be to create technology that can be changed, operated and recovered with confidence.
What should financial-services leaders ask?
For CIOs, programme sponsors, transformation leaders and operational-risk teams, five questions are especially useful:
Which important services will this change affect?
What new dependencies will we create?
How will we know if the complete service is failing?
Can we recover the business process and its data, not just restart the technology?
What evidence shows that the service is at least as resilient after the change as it was before?
If those questions are only being asked close to go-live, operational resilience has entered the programme too late.
Build resilience into transformation
Financial-services organisations cannot improve resilience by freezing their technology estate. They need to modernise.
But every significant transformation changes the environment that must be operated and recovered.
That means operational resilience should be part of the design, testing and transition of technology change.
DigX works across technology transformation, integration, data and Managed Services. These areas often form the dependencies beneath important business services.
The goal should not be to claim that technology will never fail.
It should be to create services where disruption can be detected, contained and recovered before it causes unacceptable business or customer impact.
Before the next major release, ask:
Do we know that this change makes the service more resilient — or are we simply assuming it does?
Talk to DigX about the integration, data and operational dependencies around complex technology change.
Frequently asked questions
What is operational resilience in financial services?
Operational resilience is the ability to keep important financial services running during disruption, or recover them before the disruption causes unacceptable harm to customers or markets.
What is an important business service?
Under the FCA framework, an important business service is a service provided to external customers or market participants where disruption could cause intolerable harm to consumers or pose a risk to market integrity.
What is the difference between an impact tolerance and an RTO?
An impact tolerance looks at the maximum disruption an important business service can tolerate before unacceptable harm occurs. A recovery time objective, or RTO, normally defines a technical recovery target. A system may recover before the full business service has recovered.
How can technology change affect operational resilience?
Technology change can add or remove applications, integrations, data flows, suppliers and operating processes. These changes alter the dependencies behind a service and can create new failure or recovery risks.
How should firms test operational resilience?
Testing should include realistic failure scenarios across the full business service, including technology, data, people and third parties. It should also prove that recovery procedures work in practice.
Is operational resilience the same as disaster recovery?
No. Disaster recovery normally focuses on restoring technology. Operational resilience is broader and considers whether the organisation can continue or recover the complete business service within acceptable limits.
Does operational resilience mean slowing down technology change?
No. Better testing, smaller releases, automation, strong monitoring and clear recovery plans can make change safer without stopping transformation.
